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I.  INTRODUCTION 


A.  PURPOSE 

The  purpose  of  this  thesis  is  to  analyze  whether  the  Defense  Acquisition  System 
needs  to  be  altered  to  take  advantage  of  the  implementation  of  Services-oriented 
Architecture  (SOA)  and  Open  Architecture  (OA)  principles  into  the  acquisition  of 
Integrated  Warfare  Systems  (IWS).  To  accomplish  this,  the  researchers  will  examine 
SOA  and  OA  principles,  processes  and  objectives;  the  Defense  Acquisition  System  and 
the  acquisition  lifecycle;  and  the  best  practices  of  an  emerging  Naval  acquisition  program 
and  its  SOA  implementation.  The  objective  of  this  thesis  is  to  discuss  and  generalize 
from  the  analysis  any  necessary  realignment  of  the  Defense  Acquisition  System  and  the 
acquisition  lifecycle  to  allow  new  technology  acquisition  in  military  organizations  that 
will  benefit  future  IWS  programs. 

B.  BACKGROUND 

The  United  States  Navy  is  attempting  to  restructure  its  defense  enterprise  in  a 
manner  more  suitable  to  the  current  threat  environment  and  evolving  future  threats.  The 
Navy  is  trying  to  furnish  the  warfighter  with  the  appropriate  tools  to  defend  against 
emerging  threats.  Over  the  last  few  decades,  the  Navy,  along  with  the  rest  of  the 
Department  of  Defense  (DoD),  has  increasingly  integrated  itself  by  developing  joint 
warfighting  concepts,  organizations,  training  and  operations.  However,  updates  to  the 
Navy  and  the  DoD  acquisition  policies,  processes  and  practices  have  lagged  behind, 
which  has  impeded  the  integration  effort.  Recent  experiences  have  demonstrated  the 
need  for  the  Navy  and  the  DoD  to  integrate  their  acquisition  policies,  processes  and 
practices  in  order  to  foster  joint  acquisition  solutions  for  the  warfighting  needs  of 
tomorrow. 

The  Congressional  Budget  Office  has  estimated  an  $895  billion  decrease  in 
defense  spending  between  2005  and  2014  (PEO-IWS  7.0  &  the  OA  Enterprise  Team, 
2007,  p.  8).  As  competition  for  acquisition  dollars  becomes  increasingly  strenuous,  the 
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Navy  is  challenged  with  difficult  budget  decisions.  With  inflexible  acquisition  strategies, 
the  Navy  has  become  locked  into  single  systems  and  vendors  that  limit  the  options  for 
competition  and  innovation.  The  Navy  has  acquired  systems  that  have  performed  their 
functions  and  tasks  exceedingly  well;  however,  the  Navy’s  vertical  “stove-piped”  combat 
systems  tend  to  be  localized,  preventing  the  sharing  of  information  and  technology  across 
the  different  combat  system  programs.  Acquiring  combat  systems  using  legacy  processes 
and  principles  leads  to  the  acquisition  of  combat  systems  that  have  duplicative 
capabilities,  yet  are  incompatible  and  not  interoperable.  Each  combat  system  is  unique  to 
the  platform  for  which  it  was  designed.  These  vertical  “stove-piped”  combat  systems,  the 
policies,  processes,  and  practices,  along  with  the  information  technology  (IT)  designed  to 
implement  these  systems  have  become  an  increasingly  tighter  constraint  within  the 
acquisition  process.  The  Navy  has  taken  steps  to  diminish  the  utilization  of  vertical 
“stove-piped”  combat  systems  infrastructure  and  to  shift  to  a  more  dynamic,  horizontal 
combat  systems  infrastructure  that  takes  advantage  of  advances  in  IT. 

The  Navy  is  continually  seeking  new  ways  to  develop,  field  and  support  its 
sophisticated  combat  systems  in  order  to  meet  the  future  needs  of  the  warfighter.  In  order 
to  keep  up  with  advances  in  technology,  the  Navy  has  transitioned  from  the  traditional 
detailed  MILSPEC  development  model  to  an  approach  that  stresses  open  systems  and  the 
use  of  commercial  standards  and  commercial  off-the-shelf  (COTS)  hardware  and 
software.  The  United  States  Navy  is  becoming  increasingly  interested  in  the  acquisition 
of  IWS  that  utilizes  Open  Architecture  (OA).  Open  Architecture  is  a  confluence  of 
business  and  technical  principles  that,  when  correctly  applied,  yields  modular, 
interoperable  systems  that  employs  widely  accepted  standards  and  published  interfaces 
that  lead  to  options  for  greater  competition  and  inclusion  of  innovators  (Navy  Office  of 
Information,  2006). 

An  OA  approach  combines  business  and  technical  principles  and  practices  that, 
taken  to  their  logical  conclusion,  will  change  the  acquisition  paradigm  but  will  not 
provide  the  Navy  with  solutions  for  solving  the  vertical  to  horizontal  acquisition  process. 
Joseph  UchytiPs  Naval  Postgraduate  School  thesis,  Assessing  the  Operational  Value  of 
Situational  Awareness  of  AEGIS  and  Ship  Self-Defense  System  (SSDS)  Platforms  through 
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the  Application  of  the  Knowledge  Value  Added  (KVA)  Methodology,  demonstrated  the 
operational  benefits  and  the  Return  on  Investment  (ROI)  that  could  be  realized  through 
the  application  of  an  OA  approach  to  systems  design.  Jameson  R.  Adler  and  Jennifer  L. 
Ahart’s  Naval  Postgraduate  School  thesis,  AEGIS  Platforms:  Using  KVA  Analysis  to 
Assess  Open  Architecture  in  Sustaining  Engineering,  builds  on  Uchytil’s  research  by 
assessing  the  impact  of  implementing  an  OA  development  and  acquisition  approach  to 
Sustained  Engineering  (SE)  in  IWS.  Adler  and  Ahart  demonstrated  the  benefits  of  OA 
and  the  ROI  gained  from  implementing  OA  within  SE,  and  they  laid  the  foundation  for 
the  possible  implementation  of  Services-oriented  Architecture  to  eliminate  organizational 
“stove-pipes”  within  the  acquisition  process. 

SOA  development  practices  may  provide  the  framework  and  the  components  to 
more  efficiently  develop  architectures  more  conducive  to  future  IWS.  “SOA  establishes 
an  architectural  model  that  aims  to  enhance  the  efficiency,  agility,  and  productivity  of  an 
enterprise  by  positioning  services  as  the  primary  means  through  which  solution  logic  is 
represented  in  support  of  the  realization  of  strategic  goals  associated  with  service- 
oriented  computing”  (Erl,  2008a,  p.  38).  SOA  is  not  an  entirely  new  IT  paradigm;  it 
merely  approaches  silo-based  problems  by  building  on  previously  proven  development 
processes  by  introducing  agnostic  services,  which  allows  for  increased  horizontal 
integration  (p.  84).  This  thesis  will  build  on  the  past  work  of  Uchytil,  Adler  and  Ahart  by 
examining  the  implications  of  implementing  SOA  and  OA  within  the  Defense 
Acquisition  System. 

C.  RESEARCH  OBJECTIVES 

The  research  conducted  for  this  thesis  encompasses  several  objectives.  The  first 
objective  is  to  examine  the  relational  architecture  between  SOA  and  OA  systems.  The 
second  objective  is  to  review  the  Defense  Acquisition  System  to  determine  the  feasibility 
of  moving  toward  SOA  and  OA  systems.  The  third  research  objective  is  to  identify  any 
possible  constraints  within  the  Defense  Acquisition  System  that  may  prevent  an  SOA  and 
OA  approach  in  IWS.  The  fourth  research  objective  is  to  examine  best  practices  of  Naval 
acquisition  programs  that  are  currently  incorporating  SOA  and  OA  into  their  acquisition 
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processes.  The  fifth  and  final  objective  of  the  research  is  to  examine  potential  re¬ 
alignments  of  the  Defense  Acquisition  System  that  will  allow  new  technology  acquisition 
in  military  organizations. 

D.  RESEARCH  QUESTIONS 

This  thesis  attempts  to  provide  constructive,  educational  and  useful  answers  to 
Navy  IT  decision-makers  for  three  questions,  as  well  as  providing  recommendations 
concerning  the  direction  in  which  the  Navy  and  the  DoD  may  wish  to  proceed  in  the 
future  when  acquiring  systems  that  benefit  horizontally  across  multiple  acquisition 
programs. 

•  Does  the  Defense  Acquisition  System  need  to  be  altered  to  take  advantage  of  SOA 
and  OA  implementation  into  the  acquisition  lifecycle? 

•  Do  current  Navy  OA  policies  and  SOA  practices  provide  the  necessary 
interoperability  requirements  for  future  IWS? 

•  What  benefits  might  SOA  and  OA  provide  to  IWS? 

E.  METHODOLOGY 

In  order  to  provide  a  better  understanding  of  SOA  and  OA  and  their  relationships, 
this  research  paper  first  provides  a  general  overview  of  SOA  and  OA  concepts.  In  order 
to  accomplish  this,  the  authors  will  conduct  a  literature  review  of  SOA  and  OA.  They 
will  then  examine  the  Defense  Acquisition  System  by  conducting  a  literature  review  of 
DoD  and  Naval  acquisition  policies  and  initiatives.  Next,  there  will  be  an  analysis  of 
organizational  utilization  of  SOA  and  OA  and  a  development  of  a  mini  case  study  based 
on  current  SOA  implementation  for  the  Consolidated  Afloat  Networks  and  Enterprise 
Services  (CANES)  project.  The  end  result  of  this  thesis  will  be  to  develop 
recommendations  based  on  findings  in  the  literature  reviews  and  analysis  of  the  mini  case 
study. 
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F.  SCOPE 

This  research  will  address  the  principles,  processes  and  objectives  of  SO  A  and 
OA  frameworks,  as  well  as  their  relationships  and  how  they  can  be  integrated  into  the 
Defense  Acquisition  System.  It  will  include  a  literature  review  of  SOA  and  OA,  in 
addition  to  providing  an  overview  of  the  current  Defense  Acquisition  System.  The  SOA 
development  process  for  CANES  will  be  examined,  with  concentration  on  the  planning 
and  implementation  of  the  core  services. 

G.  THESIS  ORGANIZATION 

Chapter  I  has  provided  a  general  overview  of  the  problem,  explained  the  research 
objectives,  introduced  the  thesis  questions,  and  defined  the  methodology  and  scope. 
Chapter  II  will  provide  research  and  background  information  on  Services-oriented 
Architectures,  Open  Architecture  and  the  relationship  between  them.  Chapter  III  will 
consist  of  a  review  and  evaluation  of  the  current  Defense  Acquisition  System,  SOA  and 
OA  requirements,  and  an  analysis  of  a  transition  from  the  vertical  “stove-piped” 
acquisition  process  to  a  horizontal  acquisition  process.  Chapter  IV  will  provide  a 
discussion  and  analysis  of  a  current  Navy  acquisition  program  incorporating  SOA  and 
OA  into  its  acquisition  process.  Chapter  V  will  contain  conclusions  and 
recommendations  as  well  as  topics  for  future  research. 
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II.  LITERATURE  REVIEW:  SERVICES-ORIENTED 
ARCHITECTURE  AND  OPEN  ARCHITECTURE 


A.  SERVICES-ORIENTED  ARCHITECTURE  (SOA) 

This  section  provides  a  definition  of  Services-oriented  Architecture  (SOA), 
discusses  some  SOA  influences,  outlines  SOA  concepts  and  principles,  and  discusses 
some  benefits  and  challenges  of  SOA. 

1.  Definition 

Services-oriented  Architecture  (SOA)  is  defined  differently  by  many 
organizations.  The  absence  of  a  concrete  definition  may  allow  organizations  to  more 
easily  adapt  an  SOA  to  their  current  business  processes.  Simply  defined,  SOA  is  “an 
architecture  for  a  system  or  application  that  is  built  using  a  set  of  services”  (O’Brien, 
Bass,  &  Merson,  2005,  p.  3).  Examples  of  varying  SOA  definitions  are  listed  below. 

•  An  SOA  is  “a  set  of  components  which  can  be  invoked,  and  whose 
interface  descriptions  can  be  published  and  discovered.”  (W3C, 
2004) 

•  "The  SOA  models  the  business  as  a  collection  of  self-contained 
services  that  are  available  across  the  enterprise  that  can  be  evoked 
through  standard  protocols  both  internally  and  externally." 
(McComb  as  cited  by  Mimoso,  2004) 

•  "Service  Oriented  Architecture  (SOA)  is  an  approach  to  the 
development  of  loosely  coupled,  protocol-independent  distributed 
applications  composed  from  well-defined,  self-contained  software 
resources  accessible  as  Services  across  the  extended  enterprise  in  a 
standardized  way,  enhancing  re-usability  and  interoperability." 
(Gupta  as  cited  by  Mimoso,  2004) 

•  "SOA  is  an  approach  to  building  software  applications  as 
collections  of  autonomous  services  that  interact  without  regard  to 
each  other's  platform,  data  structures,  or  internal  algorithms." 
(Champion  as  cited  by  Mimoso,  2004) 

Although  the  definition  of  SOA  varies  in  the  information  technology  industry, 
some  basic  and  useful  concepts  may  be  utilized  to  improve  processes.  Re-use, 
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interoperability,  availability,  and  standard  interface  protocols  across  an  entire  enterprise 
are  key  business  concepts  that  may  prove  beneficial  in  United  States  Naval  platforms. 
Many  organizations  already  employing  an  SOA  are  streamlining  their  processes  to  reduce 
redundancy,  thereby  reducing  costs. 

2.  Service  Definition 

“A  service  is  an  implementation  of  a  well-defined  piece  of  business  functionality, 
with  a  published  interface  that  is  discoverable  and  can  be  used  by  service  consumers 
when  building  different  applications  and  business  processes”  (O’Brien  et  ah,  2005,  p.  1). 
This  definition  gives  a  broad  overview  of  a  service  but  can  be  built  upon  to  better 
understand  what  services  can  do  for  an  organization.  Services  are  also  relatively  isolated 
from  other  services,  and  they  also  can  provide  a  “collection  of  capabilities,”  not  just  a 
single  capability.  Capabilities  with  a  common  function  may  be  contained  in  a  single 
service,  such  as  a  shipment  service.  The  shipment  service  would  incorporate  the  get,  add, 
and  report  capabilities  (Erl,  2008a,  pp.  69-70).  Organizations  must  understand  the 
capabilities  of  each  service  composed  in  their  SOA  to  reduce  redundancy  and  to  promote 
re-use  and  interoperability. 

3.  SOA  Influences 

“While  reuse,  especially  over  time,  can  be  one  of  the  most  rewarding  parts  of 
investing  in  SOA,  it  is  not  the  sole  primary  benefit.  Perhaps  even  more  fundamental  to 
service-orientation  than  promoting  reuse  is  fostering  interoperability”  (Erl,  2008a,  p.  90). 
SOA  is  not  a  design  paradigm  that  materialized  out  of  thin  air;  rather,  it  is  influenced  by 
previous  design  paradigms  and  technologies  that  leverage  the  best  practices  from  each  to 
provide  greater  interoperability  and  increase  the  re-use  potential.  Figure  1  depicts  the 
design  paradigms  and  technologies  that  represent  the  primary  influences  of  service- 
orientation.  SOA  draws  successful  and  proven  approaches  from  these  past  paradigms 
and  couples  them  with  emerging  IT  principles.  SOA  remains  in  a  state  of  evolution  and 
continues  to  be  influenced  by  the  newest  technology  innovations. 
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Figure  1.  Primary  Influences  of  Service-orientation  from 

(Erl,  2008a,  p.  97) 


4.  Re-use 

Re-use  provides  advantages  by  allowing  the  same  or  similar  process  use  in 
various  architectures,  systems,  or  applications.  The  use  of  previously  proven  concepts 
reduces  development  and  implementation  times.  Additionally,  re-use  provides  the  ability 
to  use  the  same  service  among  platforms  that  have  overlapping  missions.  Utilizing 
agnostic  services  across  multiple  platforms  reduces  system  complexity  and  future 
redesign  costs. 

Re-use  is  an  enabler  to  service  composition.  As  re-use  potential  increases,  so  do 
the  available  compositions.  Services  should  not  be  developed  for  particular 
compositions;  rather,  they  should  be  developed  to  operate  in  numerous  compositions.  As 
service  inventories  for  Naval  Integrated  Warfare  Systems  (IWS)  mature,  the  desire  is  to 
allow  multiple  applications  on  multiple  platforms  to  use  common  services.  Services 
designed  for  IWS  should  be  agnostic  enough  to  operate  across  multiple  systems. 
Correctly  designed  services  will  provide  the  necessary  compositions  required  for 
evolving  Navy  IWS  requirements. 

Historically,  re-use  has  been  highly  desired  in  the  software  industry  but  often 
difficult  to  achieve.  Typically,  “reuse  increases  the  complexity,  cost,  effort,  and  time  to 
build  software”  (Erl,  2008a,  p.  257).  Some  reasons  these  attributes  exist  are  that  software 
designers  are  designing  applications  to  fulfill  requirements  for  a  specific  process  or  only 
to  solve  immediate  problems.  Return  on  investment  (ROI)  is  easier  to  calculate  when 
using  single  purpose  applications.  Each  application  has  measurable  inputs  and  outputs 
that  equate  to  an  understandable  ROI.  “This  type  of  reasoning  is  what  has  led  to  the 
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popularity  of  siloed  application  environments”  (p.  257).  The  difficulty  associated  with 
calculating  ROI  of  reusable  services  is  more  complex,  and  the  benefits  may  not  be 
realized  at  initial  service  implementation.  As  a  service  is  re-used  and  new  service 
compositions  are  formulated,  the  ROI  will  continue  to  increase,  as  illustrated  in  Figure  2. 

traditional 
unit  of  volution 
logic 


X 

delivery  covt 


y*3 


service-oriented 
unit  of  solution 
logic 


x  +  30*>  yx2 

delivery  cost  ROI 

Figure  2.  Example  of  ROI  for  SOA  Projects  from  (Erl,  2008a,  p.  62) 

The  re-use  concept  requires  a  shift  from  traditional  system  development  and  also 
requires  stakeholders  and  architects  to  look  horizontally  across  multiple  systems  and 
consider  future  requirements  that  may  benefit  from  re-use. 

Many  Naval  systems  are  currently  developed  vertically  or  in  “silos.”  This  has  led 
to  redundant  applications  and  escalating  costs.  Re-use  among  IWS  can  alleviate  long¬ 
term  cost  burdens  and  streamline  systems.  SOA  provides  design  principles  to  guide 
Navy  IWS  toward  more  agile  systems  that  provide  better  interoperability  and  future  cost 
reductions.  There  are  differing  viewpoints  on  how  to  calculate  ROI  for  SOA,  which  will 
be  discussed  later  in  this  chapter. 
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5.  Interoperability 


Common  services  provide  seamless  interaction  with  new  and  legacy  systems, 
regardless  of  platform  specific  characteristics.  SOA  uses  interfaces  to  allow  data  sharing 
between  systems  that  were  unable  to  communicate  in  the  past.  As  legacy  systems  are 
encapsulated  and  enter  into  the  SOA-based  framework,  interoperability  becomes  more 
transparent.  Reuse  is  directly  related  to  interoperability.  As  service  reuse  increases, 
interoperability  increases,  providing  a  less  burdensome  IT  structure. 

6.  Availability 

Availability  is  the  rate  at  which  services  are  accessible.  SOA  provides  the 
advantage  of  constant  availability  since  single  components  are  responsible  for 
compartmentalized  data.  Service  availability  is  crucial  in  Naval  Integrated  Warfare 
Systems.  With  multiple  entities  relying  upon  a  given  service,  degraded  availability  may 
occur.  Complete  loss  of  a  high-demand  service  affects  all  applications  subscribing  to  that 
service.  Backup  services  should  be  considered  when  designing  an  SOA  around  critical 
systems. 


7.  Interface 

Interface  protocols  are  becoming  standard  across  industries.  The  Navy  can  use 
proven  standard  interface  protocols  to  integrate  legacy  systems  into  services-oriented 
systems.  Common  interface  protocols  allow  services  to  provide  data  to  different 
platforms,  thereby  increasing  an  enterprise’s  agility  (Gorton,  2006,  p.  152).  “Agility,  on 
an  organizational  level  refers  to  the  efficiency  with  which  an  organization  can  respond  to 
change”  (Erl,  2008a,  p.  63).  Agility  refers  to  how  quickly  services  in  an  organization  can 
be  composed  and  has  nothing  to  do  with  how  quickly  services  can  be  developed.  As 
agility  increases,  interoperability  increases  due  to  standard  interface  protocols  and  the 
time  to  change  system  components  is  reduced. 
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Services  are  linked  by  service  contracts.  Service  contracts  allow  services  to 
communicate  and  “establishes  the  terms  of  engagement,  providing  technical  constraints 
and  requirements  as  well  as  any  semantic  information  the  service  owner  wishes  to  make 
public”  (p.  126).  Service  contracts  allow  the  owner  to  permit  customers  to  see  only  the 
logic  required  to  establish  use,  while  allowing  a  service  to  remain  abstract  enough  to 
reduce  service  dependency.  Service  contracts  should  address  how  a  service  is  used  and 
also  address  the  composability  of  that  service. 

8.  Service  Location 

Once  services  are  developed  and  deemed  essential  components  for  a  given 
architecture,  service  location  must  be  addressed.  Some  systems  may  require  services 
located  in  closed  environments,  such  as  aboard  ships-where  only  applications  internally 
related  have  access  to  the  services-while  other  systems  may  subscribe  to  services 
external  to  their  enviromnent. 

In  closed  systems  with  known  services  and  service  locations,  each  service  is 
accessed  by  one  or  more  applications  but  with  limits  on  the  number  of  applications 
subscribing  to  each  service. 

Open  systems  that  subscribe  to  external  services  need  the  ability  to  process 
requests  from  large  numbers  of  subscribers.  Concerns  for  excessive  latency,  varying 
application  interfaces,  and  service  availability  may  decrease  service  reliability. 

Before  developing  any  SOA,  the  stakeholders  must  determine  which  services  are 
required,  their  locations,  how  they  are  accessed,  and  which  services  are  mission-critical. 
Ideally,  a  system  is  built  from  existing  services  to  easily  develop  an  SOA  that  provides 
desired  system  functions.  Required  services  that  do  not  exist  must  be  developed  to 
provide  desired  functions  and  should  be  agnostic,  allowing  subscription  from  other 
systems  and  applications.  Service  location  limits  re-use  and  accessibility. 

Different  SOAs  use  varying  applications  and  require  interface  protocols  for 
service  subscription  and  the  service  contracts  they  use.  Determining  service  type  and 
location  determines  the  application  interface. 
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Latency  and  availability  issues  in  mission-critical  systems  require  risk-mitigation 
solutions.  Latency  problems  surface  as  subscription  increases  for  a  given  service. 
Increased  latency  may  lead  to  unacceptable  reduced  availability  in  mission-critical 
systems.  Mission-critical  systems  require  additional  services  or  duplicate  services  to 
mitigate  risk  if  runtime  issues  cannot  be  overcome. 

9.  Loose  Coupling 

Loose  coupling  refers  to  the  dependency  of  services  upon  each  other.  An  SOA 
design  goal  is  to  reduce  the  dependency  between  services,  while  still  providing 
interoperability  within  a  system.  It  is  desirable  to  have  just  enough  coupling  to  maintain 
interoperability,  while  reducing  dependency.  As  the  dependency  loosens,  re-use  potential 
is  improved,  which  allows  service  design  more  flexibility.  Although  loose  coupling  is 
desired  in  an  SOA,  interoperability-as  stated  earlier-has  greater  importance.  Services 
should  only  have  reduced  dependency  to  a  degree  that  they  still  allow  interoperability 
between  multiple  services  and  across  multiple  applications. 

10.  SOA  Design  Standards 

Design  standards  are  central  to  SOA  development.  Although  design  standards  in 
the  infonnation  technology  environment  often  require  significant  establishment  time, 
they  also  provide  for  more  efficient  designs.  Design  standards  are  not  necessarily  new 
information  technology  standards;  they  can  be  data  standards  or  interface  standards  that 
currently  exist.  These  standards  will  allow  an  organization  to  better  understand  the 
architecture  being  pursued  and  aid  in  understanding  the  system  constraints. 

11.  Quality  of  Service  (QoS) 

Quality  of  Service  (QoS)  refers  to  the  reliability  of  data  flows  in  a  network.  QoS 
provides  different  priority  levels  to  data  flows  and  an  assurance  that  data  loss  will  be 
reduced  or  prevented.  Networks  with  limited  bandwidth  and  critical  systems  may  rely  on 
higher  QoS  levels  for  increased  reliability.  Critical  data  is  given  priority  over  less 
important  data  using  QoS  protocols.  As  critical  flows  increase,  data  flow  queue 
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management  tools  limit  lower  priority  data  flows  to  ensure  that  higher  priority  data  is 
transmitted  with  greater  reliability.  QoS  tools  are  intended  to  improve  reliability  of  data 
flows  within  a  network,  but  they  do  not  solve  bandwidth  problems  in  highly  congested 
networks.  The  Navy’s  IWS  have  many  components  with  critical  data  flows  and  will 
require  QoS  tools  to  prioritize  network  traffic. 

12.  Phased  Transition 

An  organization  should  develop  detailed  plans  using  an  architecture  evaluation 
method  prior  to  implementation  of  a  complete  SOA.  Rather  than  attempting  to  transition 
an  enterprise  from  legacy  systems  to  a  complete  SOA  all  at  once,  incremental 
implementation  is  recommended.  Architectural  evaluations  will  mitigate  risks  for  each 
planned  increment  and  alleviate  potential  re-work.  Incremental  implementation  also 
allows  an  organization  time  to  adjust  to  changes  and  provides  an  environment  fostering 
adaptation  and  acceptance  as  personnel  become  more  familiar  with  new  systems.  Users 
may  have  difficultly  adapting  to  entirely  new  systems  and  may  resist  an  SOA  if  they  are 
not  given  time  to  understand  the  new  systems.  To  mitigate  change  management  risks,  a 
phased  transition  is  recommended  (Erl,  2008a,  p.  87). 

13.  Governance 

Governance  refers  to  the  application  of  processes  utilized  throughout  an 
organization  when  developing  an  SOA.  These  processes  govern  how  SOAs  are  designed, 
developed,  implemented,  and  maintained,  which  ensures  conformity  to  the  guiding 
architectural  principles  and  regulations  established  by  the  organization.  “Governance 
represents  the  responsibility  of  administering,  maintaining,  and  evolving  what  is 
delivered  by  SOA  projects”  (Erl,  2008b,  p.  97). 

14.  ROI 

As  stated  earlier  in  this  chapter,  there  are  differing  viewpoints  on  how  to  calculate 
return  on  investment  (ROI)  for  SOA.  Experts  argue  the  feasibility  of  calculating  ROI  for 
SOA. 
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What  makes  calculating  the  ROI  of  SOA  even  more  challenging  is  that 
architecture,  by  itself,  doesn’t  offer  specific  features  that  companies  can 
readily  identify  with  some  particular  return.  After  all,  architecture  is  an 
investment  that  companies  must  make  well  in  advance  of  any  return,  and 
must  continue  to  make  over  the  lifetime  of  their  SOA  implementations. 
(Schmelzer,  2005) 

Some  experts  believe  ROI  for  SOA  does  not  provide  a  true  measure  of 
benefits  since  the  calculated  ROI  is  based  upon  components  that  make  up 
the  system  and  these  measures  do  not  capture  the  benefits  of  the  entire 
solution.  SOA  is  a  set  of  best  practices,  a  philosophy,  and  a  drive  toward 
business  transformation.  SOA,  for  the  most  part,  is  intangible,  with  long¬ 
term  results  to  the  business.  (McKendrick,  2007) 

The  larger  issue  is  that  SOA,  at  the  end  of  the  day,  is  a  systemic  change  in 
the  way  organizations  approach  enterprise  architecture.  Thus,  the  benefits 
will  only  be  understood  when  the  architecture  has  undergone  that  change. 
(Linthicum,  2007) 

Although  some  experts  do  not  believe  there  is  real  value  in  calculating  ROI  of  an 
SOA,  others  believe  it  is  required  and  are  using  innovative  methods  to  calculate  ROI  for 
SOA.  “Some  measure  of  ROI  is  nearly  always  used  as  a  justification  for  major 
technology  investments  within  large  enterprises”  (Gabhart,  2007,  p.  1).  Gabhart  divides 
SOA  ROI  calculations  into  three  quantifiable  benefits  of  SOA:  “Tactical  ROI  as  a  result 
of  standards-based  service  oriented  integration,  Operational  ROI  based  on  service  and 
process  reuse,  and  Strategic  ROI  due  to  business  and  technology  agility”  (p.  2). 

Tactical  ROI  focuses  on  reducing  redundancy  and  other  initial  cost  reductions  to 
provide  justification  for  initiating  an  SOA.  The  four  steps  listed  below  describe  the 
method  for  calculating  tactical  ROI. 

•  Compute  the  savings  realized  due  to  reduced  middleware  licensing  costs. 

•  Compute  the  savings  afforded  due  to  reduced  development  time. 

•  Project  savings  due  to  reduced  maintenance  costs. 

•  Add  the  results  of  steps  1-3  together  and  fold  that  into  whatever  ROI  formula 
your  organization  uses  (i.e.  net  gain  divided  by  investment).  (Gabhart,  2007, 
P-2) 
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As  previously  stated,  tactical  ROI  is  just  an  initial  figure  for  SOA  justification. 
Operational  and  strategic  ROI  must  be  analyzed  to  provide  more  accurate  estimations  of 
an  SOA’s  value. 

Operational  ROI  provides  information  for  “the  short  to  medium  time  frame,”  by 
analyzing  the  re-use  of  services.  Two  methods  for  calculating  operational  ROI  for  SOA 
are  the  iterative  re-use  model  and  the  calculated  re-use  model.  When  using  the  iterative 
re-use  model,  the  “investment  return  is  measured  based  on  the  number  of  times  a  service 
or  process  is  reused  rather  than  an  arbitrary  time  frame”  (Gabhart,  2007,  p.  3). 
Development  of  reusable  components  may  initially  cost  much  greater  than  non-reusable 
components,  but  the  cost  savings  are  realized  upon  each  successive  re-use  of  a  given 
service.  The  calculated  re-use  model  is  a  “mathematical  model  [that]  computes  SOA 
value  based  upon  a  few  key  variables  such  as  number  of  services  available  for  reuse, 
degree  of  reuse,  and  service  complexity”  (p.  3).  This  method  requires  an  organization  to 
compare  current  non-SOA  development  component  costs  to  those  that  are  developed  for 
re-use  in  an  SOA. 

Strategic  ROI  should  be  calculated  to  provide  a  complete  analysis  of  the  long¬ 
term  benefits  gained  by  implementing  an  SOA. 

Strategic  ROI  is  manifested  though  cost  controls,  risk  mitigation,  and  new 
revenue  generation  as  a  result  of  agility... Strategic  ROI  is  the  ultimate 
expression  of  what  SOA  is  all  about.  It’s  about  making  a  strategic 
investment  in  an  agile  enterprise  infrastructure  and  at  the  same  time 
aligning  the  business  and  technology  sides  of  the  organization  to  work 
toward  common,  shared  objectives.  (Gabhart,  2007,  p.  4) 

Listed  below  are  guidelines  for  calculating  strategic  ROI.  It  is  important  to 
understand  that  strategic  ROI  is  more  an  art  than  a  science. 

•  System  development  and  maintenance  costs  saved  due  to  the  ability  to 
modify  infonnation  systems  with  little  to  no  coding  required  (simply 
modify  or  rearrange  the  orchestration  of  several  services). 

•  Estimated  legal  costs  and  fines  avoided  due  to  faster  and  more  reliable 
responsiveness  to  regulatory  changes. 

•  Revenue  generated  via  the  rapid  creation  of  new  services  as  well  as  the 
manipulation  and  reconfiguration  of  existing  ones. 
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•  Revenue  generated  due  to  ability  to  expose  internal  capabilities  as 
consumable  services  by  business  partners  and  clients  (this  potentially 
generates  completely  new  streams  of  income).  (Gabhart,  2007,  p.  4) 

Calculating  ROI  for  an  SOA  is  not  a  concept  that  gains  consensus  from  all  SOA 
experts,  but  as  more  organizations  migrate  to  SOA,  methods  for  ROI  calculation  are 
emerging.  Gabhart’ s  method  is  only  one  recommendation  for  calculating  the  ROI  for  an 
SOA.  Employing  Gabhart ’s  method  provides  guidelines  for  initial  ROI  estimates  as  well 
as  medium  to  long  term  ROI  estimates.  In  the  future,  managers  are  not  likely  to  proceed 
with  any  IT  endeavor  that  lacks  measures  for  providing  a  return  on  investment. 

15.  SOA  Benefits 

Silo-based  systems  make  architectural  evolution  difficult  due  to  multiple  systems 
with  independent  architectures  that  are  not  compatible.  The  Navy  currently  acquires 
systems  vertically  (as  separate  acquisition  processes).  Service-orientation  solves  the 
evolution  issues,  since  systems  can  be  developed  horizontally  across  many  acquisition 
programs.  Once  horizontal  development  begins,  all  programs  utilizing  an  SOA  can  begin 
development  using  a  common  framework  and  components,  consequently,  reducing 
design  time,  implementation  time,  and  overall  cost  reduction. 

Service-orientation  attempts  to  solve  past  problems  by  designing  for  the  concepts 
listed  below  (Erl,  2008a,  p.  81). 

•  Increased  consistency  in  how  functionality  and  data  is  represented 

•  Reduced  dependencies  between  units  of  solution  logic 

•  Reduced  awareness  of  underlying  solution  logic  design  and 
implementation  detail 

•  Increased  opportunities  to  use  a  piece  of  solution  logic  for  multiple 
purposes 

•  Increased  opportunities  to  combine  units  of  solution  logic  into 
different  configurations 

•  Increased  behavioral  predictability 

•  Increased  availability  and  scalability 

•  Increased  awareness  of  available  solution  logic 
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16.  SOA  Challenges 


Some  challenges  that  SOA  systems  face  are  outlined  below  (Erl,  2008a,  p.  85): 

•  Increased  performance  requirements:  As  multiple  systems  reuse  a 
single  service,  system  performance  needs  to  increase  to  keep  up 
with  demand  and  prevent  latency  issues.  Performance  measures 
will  need  to  be  developed  for  each  service  based  on  intended 
usage. 

•  Reliability  due  to  concurrent  usage:  A  service  may  exhibit  reduced 
reliability  as  more  than  one  system  is  requiring  that  service’s 
functions  at  the  same  time.  Controls  to  mitigate  the  risk  of  reduced 
reliability  must  be  introduced  for  critical  systems. 

•  Single  point  failure:  As  an  increasing  number  of  systems  rely  on 
one  service  for  a  particular  function  or  process,  failure  of  the 
service  will  impact  every  system  relying  upon  that  service. 
Governance  may  aid  in  mitigating  this  risk.  Backup  systems  are 
not  ideal,  but  should  be  considered  for  high-risk  processes. 

•  Increased  demand  on  hosting  environments:  As  demand  on 
hosting  environments  increases,  runtimes  may  become  excessive 
and  lead  to  excessive  latency  issues.  Hosting  environments  will 
need  to  be  scalable  to  mitigate  increased  demand.  Concurrent 
requests  from  multiple  applications  must  be  addressed  to  reduce 
latency  issues  as  a  service  processes  these  requests. 

•  Service  contract  versioning  issues  and  redundant  service  contracts: 
Service  contracts  address  how  services  will  interface  with  various 
applications  and  describe  their  desired  functionality.  Versioning 
must  be  standardized  to  avoid  confusion  and  redundant  operations 
that  may  lead  to  increased  runtime.  Proper  governance  will  reduce 
the  likelihood  of  versioning  issues  and  redundant  service  contracts. 

B.  OPEN  ARCHITECTURE  (OA) 

This  section  defines  Open  Architecture  (OA),  introduces  and  defines  Naval  Open 
Architecture  (NOA),  outlines  the  NOA  strategy  and  business  model,  and  discusses  how 
the  Navy  assesses  the  “openness”  of  its  programs. 

1.  Definition 

The  concepts  of  open  architecture  (OA)  have  been  around  for  years.  Simply  put, 
OA  is  an  architecture  that  employs  open  standards  for  key  interfaces  within  a  system. 
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What  this  means  is  that  the  components  of  a  system  or  a  system-of-systems  are  easily 
interchangeable,  simply  plug  and  play.  OA  principles  encompass  both  the  business 
processes  and  technical  practices  that  enable  modular,  interoperable  systems  that  adhere 
to  open  standards.  These  principles  apply  to  both  the  construction  of  a  system  and  the 
management  of  its  lifecycle.  The  fundamental  drivers  of  OA  are  to  reduce  total 
ownership  costs  and  time  to  deliver  a  system.  The  goals  of  OA  are  to 

•  Increase  Reuse 

•  Increase  Flexibility 

•  Faster  Time  to  Market 

•  Reduce  Costs 

•  Leverage  Competition 

•  Improve  Interoperability 

•  Reduce  Risk  (Nelson,  2007,  p.  8) 

OA  principles  are  intended  to  support  these  goals  and  fundamental  drivers  by 
identifying  the  key  business  processes  and  technical  practices  that  aid  in  the  construction 
and  deployment  of  OA  systems. 

2.  Naval  Open  Architecture  (NOA) 

In  the  commercial  environment,  new  technologies  have  driven  the  market  to  adapt 
to  a  modular  open  systems  approach  to  developing  new  systems.  This  same  environment 
has  also  affected  the  acquisition  of  National  Security  Systems  (NSS)  across  the  DoD. 
The  Navy,  having  realized  the  impacts  and  opportunities  associated  with  open 
architecture,  has  implemented  its  own  open  architecture  policy.  Naval  Open  Architecture 
(NOA)  is  an  enterprise-wide,  multi-faceted  business  and  technical  strategy  for  acquiring 
and  maintaining  NSS  as  interoperable  systems  that  adopt  and  exploit  open  system  design 
principles  and  architectures  (PEO-IWS,  2007). 

The  NOA  website  defines  its  open  architecture  as  “a  Navy  initiative  for  a  multi¬ 
faceted  strategy  providing  a  framework  for  developing  joint  interoperable  systems  that 
adapt  and  exploit  open-system  design  principles  and  architectures”  (DAU,  2006,  p.  13). 
This  framework  includes  a  set  of  principles,  processes,  and  best  practices  that: 
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•  Provide  more  opportunities  for  competition  and  innovation 

•  Rapidly  field  affordable,  interoperable  systems 

•  Minimize  total  ownership  cost 

•  Optimize  total  system  perfonnance 

•  Yield  systems  that  are  easily  developed  and  upgradeable 

•  Achieve  component  software  reuse  (p.  13) 

3.  NOA  Strategy 

In  order  to  help  implement  its  open  architecture  framework,  the  Navy  has 
developed  an  overarching  NOA  strategy.  This  strategy  includes  a  vision  statement, 
principles,  goals  and  supporting  objectives.  The  NOA  vision  is  to  “transform  our 
organization  and  culture  and  align  our  resources  to  adopt  and  institutionalize  open 
architecture  principles  and  processes  throughout  the  naval  community  in  order  to  deliver 
more  warfighting  capabilities  to  counter  current  and  future  threats”  (PEO-IWS,  2007,  p. 
1). 


In  order  to  achieve  the  NOA  vision,  five  underlying  principles  have  been 
identified.  These  five  principles  are: 

1.  Encourage  competition  and  collaboration  through  the  development  of 
alternative  solutions  and  sources. 

2.  Build  modular  designs  and  disclose  data  to  permit  evolutionary  designs, 
technology  insertion,  competitive  innovation,  and  alternative  competitive 
approaches  from  multiple  qualified  sources. 

3.  Build  interoperable  joint  warfighting  applications  and  ensure  secure 
information  exchange  using  common  services  (e.g.,  common  time 
reference),  common  warfighting  applications  (e.g.,  track  manager)  and 
information  assurance  as  intrinsic  design  elements. 

4.  Identify  or  develop  reusable  application  software  selected  through  open 
competition  of  “best  of  breed”  candidates,  reviewed  by  subject-matter- 
expert  peers  and  based  on  data-driven  analysis  and  experimentation  to 
meet  operational  requirements. 
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5.  Ensure  lifecycle  affordability  including  system  design,  development, 
delivery,  and  support  while  mitigating  Commercial  off-the-Shelf  (COTS) 
obsolescence  by  exploiting  the  Rapid  Capability  Insertion 
Process/ Advanced  Processor  Build  methodology.  (PEO-IWS,  2007,  p.  2) 

In  order  to  adhere  to  these  five  principles,  the  Navy  has  established  several  goals 
and  supporting  objectives.  While  the  following  goals  define  the  direction  for  the  Navy’s 
software  architectures,  the  supporting  objectives  strengthen  each  goal  by  describing  how 
they  will  be  accomplished.  The  goals  and  their  supporting  objectives  are  outlined  below. 

Goal  1: 

Change  Naval  processes  and  business  practices  to  utilize  open  systems 
architectures  in  order  to  rapidly  field  affordable,  interoperable  systems. 

Supporting  Objectives: 

1.  Provide  and  refine  policies,  guidance  and  definitions  required  to 
establish  a  common  approach  for  Naval  OA. 

2.  Support  OPNAV  in  coordinating  budget  guidance  across  combat  system 
and  C4ISR  communities,  exploiting  synergies  across  existing  programs  of 
record,  to  support  Naval  Power  21  priorities. 

3.  Assist  the  Milestone  Decision  Authority,  Program  Manager,  and 
Resource  Sponsor  in  assessing  program  openness,  where  appropriate,  to 
make  informed  OA  investment  decisions. 

4.  Implement  and  refine  OA  Contract  Guidance  for  use  in  applicable 
procurements  tailored  as  necessary  to  meet  domain-specific  requirements. 

5.  Facilitate  cross-domain  component  reuse  to  reduce  costs  and  enable 
more  effective  technology  insertion.  (PEO-IWS,  2007,  pp.  2-3) 


Goal  2: 

Provide  Naval  OA  systems  engineering  leadership  to  field  common, 
interoperable  capabilities  more  rapidly  at  reduced  costs. 
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Supporting  Objectives: 


1.  Conduct  Naval  OA  systems  engineering  experimentation  to  facilitate 
the  fielding  of  interoperable  capabilities  and  encourage  collaboration. 

2.  Oversee  Naval  OA  implementation  efforts  ensuring  standardized  and 
disciplined  processes  are  utilized  across  domains. 

3.  Identify  and  foster  "quick  win"  candidates  and  near-term  proofs  of 
concept  for  OPNAV  to  field  additional  capabilities  at  reduced  costs. 

4.  Ensure  the  Naval  OA  process  remains  relevant  to  S&T  advancement. 

5.  Work  with  the  Test  &  Evaluation  (T&E)  community,  academia,  and 
industry  partners  to  identify  opportunities  for  reducing  T&E  expenses  as  a 
result  of  OA.  (PEO-IWS,  2007,  pp.  2-3) 

Goal  3: 

Change  Navy  and  Marine  Corps  Cultures  to  Institutionalize  OA 
Principles. 

Supporting  Objectives: 

1.  Increase  awareness  of  Naval  OA  through  the  development  of  standard 
communication  tools  (i.e.  presentations,  papers,  web  content). 

2.  Increase  workforce  skill  sets  through  targeted  training  and  ongoing 
research. 

3.  Conduct  Outreach  to  External  Stakeholders  to  increase  the  awareness  of 
the  Naval  OA  initiative.  (PEO-IWS,  2007,  pp.  2-3) 


4.  Open  Architecture  Enterprise  Teams  (OAET) 

To  implement  the  Naval  OA  strategy,  Navy  leadership  established  a  Naval  Open 
Architecture  Enterprise  Team  (OAET).  The  Program  Executive  Officer  Integrated 
Warfare  Systems  (PEO-IWS)  was  assigned  overall  responsibility  and  authority  for 
directing  the  NOA  effort  and  was  designated  as  the  OAET  lead.  Representatives  from 
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AIR,  SURFACE,  SUBS,  SPACE,  C4I  and  Marine  Corps  domains  are  incorporated  into 
the  OAET  to  ensure  that  NOA  principles,  guidelines,  business  practices,  and  technical 
solutions  are  utilized  across  the  enterprise  and  within  each  domain.  The  OAET  is 
responsible  for  developing  an  overarching  OA  acquisition  and  business  strategy  (Young, 
2004,  August  5). 

5.  NOA  Business  Model 

The  Navy  has  developed  an  OA  business  model  to  help  guide  the  acquisition 
process.  The  Navy’s  OA  business  model  focuses  on  several  key  principles,  including  the 
utilization  of  performance  specifications;  specialization  at  the  module  or  component 
level;  defining  roles  and  responsibilities  for  component  delivery,  system  integration  and 
lifecycle  support;  and  the  criticality  of  a  “spiral”  or  “build  test  build”  process  (DAU, 
2006,  p.  3).  Figure  3  illustrates  the  Navy’s  OA  business  model. 
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Figure  3.  OA  Business  Model  from  (DAU,  2006,  p.  2) 


6.  NOA  Tools 

The  OAET  has  developed  an  assessment  model  and  an  assessment  tool  to  help 
program  managers  evaluate  the  “openness”  of  their  respective  program  or  system.  The 
Open  Architecture  Assessment  Model  (OAAM)  is  a  descriptor  of  the  openness  of  a 
program  or  system.  The  OAAM  was  developed  to  provide  program  managers  a  means  of 
describing  the  openness  of  their  program  or  system.  Program  managers  accomplish  this 
by  assessing  their  respective  program  or  system  and  detennining  the  “as-is”  level  of 
openness  and  the  desired  “to-be”  level  of  openness.  The  OAAM  provides  a  macro-level 
evaluation  of  the  program  or  system  and  is  not  meant  to  provide  improvements  but  rather 
to  uncover  alternatives  for  creating  more  openness. 
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The  Open  Architecture  Assessment  Tool  (OAAT)  provides  two  functions:  1)  a 
descriptive  measure  of  a  program’s  or  system’s  level  of  OA  maturity  and  2)  a  means  by 
which  a  program  manager  can  detennine  where  his  or  her  program  stands  with  regards  to 
what  is  possible  (Shannon,  2006,  October  19).  The  OAAT  is  an  analytical  tool  that 
assesses  the  openness  of  a  program  or  system  based  on  business  and  technical  interrelated 
questions.  The  OAAT  implements  the  OAAM  as  a  descriptor  and  provides  a  reproducible 
and  more  consistent  method  of  evaluating  a  program  or  system. 

Employing  the  OAAM  and  OAAT  is  a  continuous  process  that  identifies  a 
program’s  or  system’s  current  state  of  openness,  desired  state  of  openness,  and  the 
alternatives  to  progress  from  the  current  state  to  the  desired  state.  As  alternatives  are 
examined,  a  business  case  is  developed  to  determine  the  progression  toward  the  desired 
state  of  openness.  The  OAAM  and  OAAT  should  be  used  during  all  phases  of  the 
acquisition  process  in  order  to  continually  assess  and  facilitate  the  OA  maturity  of  a 
program  or  system. 

C.  SOA  AND  OA  RELATIONSHIP 

The  previous  sections  discussed  the  background  of  SOA  and  OA.  This  section 
will  discuss  the  relationship  between  SOA  and  OA. 

An  SOA  can  be  built  using  proprietary  means;  however,  this  type  of  SOA  would 
not  take  full  advantage  of  the  strategic  goals  and  benefits  of  utilizing  an  SOA.  Therefore, 
to  fulfill  the  SOA  vision,  an  SOA  should  focus  on  exploiting  open  standards  and  OA 
principles. 

1.  Strategic  Goals  and  Benefits  of  SOA 

There  are  several  strategic  goals  and  benefits  associated  with  an  SOA.  The 
strategic  goals  of  an  SOA  are: 

•  Increased  Intrinsic  Interoperability 

•  Increased  Federation 

•  Increased  Vendor  Diversity  Options 

•  Increased  Business  and  Technology  Alignment  (Erl,  2008b,  p.  12) 
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The  strategic  goals  of  an  SOA  lead  to  the  attainment  of  the  strategic  benefits, 
which  are: 

•  Increased  ROI 

•  Reduced  IT  Burden 

•  Increased  Organizational  Agility  (p.  12) 

The  strategic  goals  and  benefits  of  an  SOA  are  long-term  goals  and  are  intended 
to  improve  the  IT  environment  throughout  the  entire  enterprise.  These  long-term 
strategic  goals  contrast  the  previously  used  tactical  goals  of  traditional  “stove-piped” 
applications  that  focused  on  meeting  short-tenn  requirements. 

2.  Applying  Open  Standards  and  OA  Principles 

Employing  open  standards  and  applying  OA  principles  to  an  SOA  promote  the 
strategic  goals  and  benefits  of  the  SOA.  Applying  OA  principles  increases  the  flexibility 
of  software  applications  by  utilizing  standard  interfaces  that  increase  the  interoperability 
of  different  systems.  Open  standards  promote  vendor  diversification  by  abstracting 
proprietary  implementation  details,  which  allows  vendors  to  easily  integrate  system 
components.  As  new  technologies  are  developed,  open  standards  and  OA  principles 
pennit  interfaces  that  are  technologically  neutral,  which  allows  systems  to  be  easily 
upgradeable  and  interchangeable. 

D.  SUMMARY 

This  chapter  defined  important  tenns,  concepts  and  principles,  and  defined  the 
relationship  between  SOA  and  OA.  Services-Orientated  Architecture  and  design  is  a 
relatively  new  and  emerging  paradigm  that  increases  system  interoperability.  Experts’ 
definitions  vary  on  what  and  how  an  SOA  is  designed  and  implemented,  but  most  agree 
on  core  concepts.  SOA  increases  interoperability  across  multiple  systems  that  previously 
had  very  centralized  processes.  IWS  can  benefit  from  SOA  as  common  services  are  used 
across  multiple  platforms.  Reuse  is  another  benefit  SOA  aspires  to  provide.  As  service 
re-use  increases,  IWS  will  be  modified  more  easily  and  ROI  will  increase  as  redundant 
applications  are  replaced  by  composable  service  structures.  SOA  provides  the  benefit  of 
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incremental  implementation  that  reduces  integration  issues  and  allows  organizations  to 
adapt  to  an  SOA  over  time.  Challenges  exist  when  implementing  an  SOA,  but  with 
proper  planning  and  architectural  evaluations  many  risks  are  mitigated. 

The  Navy  currently  follows  the  DoD  guidance  requiring  exploration  of  OA 
software  systems.  To  further  OA  use  within  Naval  systems,  the  Navy  should  begin  to 
combine  the  use  of  OA  with  other  emerging  technologies  such  as  SOA  and  services- 
oriented  computing.  The  next  chapter  will  examine  the  current  Defense  Acquisition 
System  in  order  to  help  answer  the  first  thesis  question. 
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III.  DEFENSE  ACQUISITION  SYSTEM 


A.  INTRODUCTION 

The  previous  chapter  provided  some  background  information  on  the  basic 
principles  and  concepts  behind  Services-oriented  Architectures  (SOA)  and  Open 
Architectures  (OA),  defined  the  relationship  between  them,  and  discussed  some  of  the 
benefits  of  incorporating  SOA  and  OA  into  IWS.  This  chapter  will  focus  on  the  current 
Defense  Acquisition  System  and  will  provide  an  explanation  of  how  to  incorporate  SOA 
and  OA  into  the  acquisition  process  in  order  to  provide  an  answer  to  the  first  thesis 
question:  “Does  the  Defense  Acquisition  System  need  to  be  altered  to  take  advantage  of 
SOA  and  OA  implementation  into  the  acquisition  lifecycle?” 

Within  the  Defense  Acquisition  System,  there  are  three  major  decision-support 
systems  utilized  by  defense  leaders  to  enable  proper  decision-making  concerning  the 
acquisition  of  National  Security  Systems.  These  decision  support  systems  include  the 
Joint  Capabilities  Integration  and  Development  System  (JCIDS);  the  Defense  Acquisition 
System;  and  the  Planning,  Programming,  Budgeting  and  Execution  System  (PPBE).  The 
incorporation  of  SOA  and  OA  into  IWS  impacts  each  of  these  three  decision  support 
systems.  The  focal  point  of  this  chapter  will  be  the  impacts  of  SOA  and  OA  within  the 
Defense  Acquisition  System  decision  support  process  and  the  acquisition  lifecycle. 
Although  this  research  will  focus  on  the  Defense  Acquisition  System  and  the  acquisition 
lifecycle,  the  paper  will  also  touch  on  a  few  impacts  SOA  and  OA  may  have  within  the 
JCIDS  process.  Additionally,  the  Naval  Open  Architecture  (NOA)  policy  guidance  and 
its  application  to  help  develop  SOA  policy  guidance  will  be  discussed,  as  well  as  other 
factors  affecting  SOA  and  OA. 

B.  DODD  5000.1 

The  DoDD  5000.1  is  a  directive  that  applies  to  all  acquisition  programs  in  the 
Department  of  Defense.  The  directive’s  purpose  is  to  provide  management  principles, 
mandatory  policies,  and  procedures  to  managers  for  all  current  and  future  acquisition 

29 


programs.  This  directive  provides  definitions  for  the  Defense  Acquisition  System,  an 
Acquisition  Program,  the  Defense  Acquisition  Executive  (DAE),  the  Milestone  Decision 
Authority  (MDA),  and  the  Program  Manager  (PM).  The  directive  sets  the  policy  and  is 
the  basic  guidance  required  for  all  DoD  acquisition  programs. 

1.  Policy 

The  Defense  Acquisition  System  is  a  complex  and  multi-faceted  system  utilized 
by  the  Department  of  Defense  (DoD)  in  the  acquisition  of  its  National  Security  Systems. 
The  purpose  of  the  Defense  Acquisition  System  is  best  described  in  the  following  quote. 

The  Defense  Acquisition  System  exists  to  manage  the  nation's  investments 
in  technologies,  programs,  and  product  support  necessary  to  achieve  the 
National  Security  Strategy  and  support  the  United  States  Anned  Forces. 

The  investment  strategy  of  the  Department  of  Defense  shall  be  postured  to 
support  not  only  today's  force,  but  also  the  next  force,  and  future  forces 
beyond  that.  (Under  Secretary  of  Defense  (AT&L),  2003a,  p.  3) 

The  Defense  Acquisition  System  is  governed  by  five  fundamental  policies: 
flexibility,  responsiveness,  innovation,  discipline,  and  streamlined  and  effective 
management.  Acquisition  programs  for  SOA  and  OA  are  based  upon  principles  that  meet 
the  requirements  of  these  five  governing  policies.  The  following  paragraphs  will 
describe  how  SOA  and  OA  support  the  five  fundamental  policies  set  forth  in  the  DoDD 
5000.1. 


a.  Flexibility 

SOA  and  OA  systems,  once  established  in  an  organization,  provide 
flexibility  through  increased  agility  and  potential  re-use  opportunities.  As  these  systems 
mature,  they  increase  flexibility,  allowing  the  systems  to  adapt  quickly  to  time-sensitive 
needs. 


b.  Responsiveness 

SOA  and  OA  provide  the  necessary  responsiveness  for  deploying  systems 
to  the  warfighter  in  the  “shortest  time  practicable.”  As  stated  previously,  SOA  should  be 
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incorporated  incrementally  and  will  require  considerable  time  to  fully  mature. 
Responsiveness  will  improve  as  SOA  and  OA  systems  mature. 


c.  Innovation 

The  DoD  requires  MDAs  and  PMs  to  explore  innovative  technologies  to 
reduce  cycle-times  and  costs.  SOA  and  OA  are  proven  innovative  technologies  in  the 
commercial  market  and  are  gaining  acceptance  in  the  DoD.  OA  is  intended  to  reduce 
costs  and  development  times.  The  Navy  has  already  realized  the  need  to  migrate  to  OA 
systems.  SOA  is  intended  to  increase  interoperability  and  reduce  redundant  systems  and 
components,  therefore  reducing  future  cost  and  cycle-time  associated  with  DoD 
networks. 


d.  Discipline 

SOA  and  OA  systems  require  the  same  level  of  discipline  that  is  required 
of  any  acquisition  program-the  difference  is  in  the  baseline  parameters.  Since  these 
technologies  are  relatively  new,  standard  baseline  parameters  and  exit  criteria  will  need 
to  be  developed  over  time  as  data  is  gathered  on  programs  using  these  technologies. 

e.  Streamlined  and  Effective  Management 

Streamlined  and  effective  management  can  mitigate  risks  as  each  program 
is  documented  to  produce  credible  cost,  schedule,  and  perfonnance  parameters. 
Managers  must  be  flexible,  as  these  technologies  will  require  multiple  MDAs  and  PMs  to 
mutually  support  programs  across  system  and  program  boundaries. 

2.  Modular  Open  Systems  Approach  (MOSA) 

The  DoD  recognizes  the  performance  and  total  ownership  cost  advantages  that  a 
modular  open-systems  approach  (MOSA)  provides.  “A  modular,  open-systems  approach 
shall  be  employed,  where  feasible”  (Under  Secretary  of  Defense  (AT&L),  2003a,  p.  9). 
MOSA  is  defined  as  “an  integrated  business  and  technical  strategy  that  employs  a 
modular  design  and,  where  appropriate,  defines  key  interfaces  using  widely  supported, 
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consensus  based  standards  that  are  published  and  maintained  by  a  recognized  industry 
standards  organization”  (OSJTF,  2004,  p.  6).  MOSA  is  considered  a  key  enabler  to 
evolutionary  acquisition  and  supports  many  principles  that  are  consistent  with  SOAs. 
Combining  a  MOSA  with  an  SOA  may  reinforce  the  objectives  presented  in  the  OSJTF 
guide  (2004).  As  seen  in  Figure  4,  the  principles  and  benefits  that  OSJTF  states  as  being 
enabled  by  MOSA  are  also  supported  when  using  an  SOA. 

Modular  Open  Systems  Approach 

(MOSA) 


Vision  Principles  Benefits 


MOSA  is  an 
integral  part  of  all  i 
acquisition  strategies  to 
achieve  affordable, 
evolutionary, 
and  joint  combat 
capability  * 


Establish  Enabling  Environment 


Employ  Modular  Oesign 


Designate  Key  Interfaces 


Select  Open  Standards 


Certify  Conformance 


Y  Ease  of  Change 

Y  Reduced  Total  Ownership  Cost 

Y  Reduced  Cycle-Time 

Y  Enabling  Joint  Integrated 
Architectures  and  Interoperability 

Y  Risk  Mitigation 


Indicators 

Figure  4.  Modular  Open  Systems  Approach  from 

(OSJTF,  2004,  p.  3) 


The  guidance  in  the  DoDD  5000.1  and  the  OSJTF  guide  mandate  the  use  of  open- 
systems  architectures  and  support  concepts  integral  to  SOA.  Instead  of  inhibiting  SOA 
use,  these  documents  enable  SOA  through  the  requirements  established  for  using  MOSA. 
OA  and  SOA  are  approaches  that  optimize  total  system  performance  and  minimize  total 
ownership  costs. 
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The  DoDD  5000.1  is  the  primary  directive  that  must  be  followed  by  all 
acquisition  programs.  The  DoDD  5000.2  is  the  instruction  for  the  operation  of  the 
Defense  Acquisition  System  and  is  discussed  in  the  next  section. 

C.  DODI  5000.2 

The  DoDI  5000.2  is  the  instruction  for  the  operation  of  the  Defense  Acquisition 
System.  This  instruction  establishes  an  acquisition  management  framework;  creates  a 
framework  for  developing  technology  opportunities;  sets  the  requirement  for  using 
integrated  architectures;  and  describes  evolutionary  acquisition  as  the  preferred  DoD 
strategy  for  rapid  acquisition  programs.  This  section  will  focus  on  the  acquisition 
management  framework,  integrated  architectures,  evolutionary  acquisition,  and 
technology  opportunities  for  the  DoD  acquisition  programs. 

1.  Defense  Acquisition  Management  Framework 

The  DoDI  5000.2  provides  a  “simplified  and  flexible  management  framework  for 
translating  mission  needs  and  technology  opportunities,  based  on  approved  mission  needs 
and  requirements,  into  stable,  affordable,  and  well-managed  acquisition  programs  that 
include  weapon  systems  and  automated  information  systems  (AISs)”  (Under  Secretary  of 
Defense  (AT&L),  2003b,  p.  1).  The  framework,  provided  by  DoDI  5000.2,  “authorizes 
Milestone  Decision  Authorities  (MDAs)  to  tailor  procedures  to  achieve  cost,  schedule, 
and  performance  goals”  (p.  1).  The  flexibility  of  the  acquisition  management  framework 
outlined  in  the  DoDI  5000.2  and  the  ability  to  tailor  it  to  the  needs  of  the  program  is  a  key 
enabler  for  incorporating  SOA  and  OA  into  IWS.  The  development  processes  of  SOAs 
and  OAs  differ  greatly  from  those  of  legacy  systems  and  must  be  tailored  to  capture  the 
objectives  of  the  enterprise.  Aligning  an  SOA  or  OA  with  the  objectives  of  the  enterprise 
necessitates  flexibility  within  the  acquisition  management  framework.  Figure  5 
illustrates  the  defense  acquisition  management  framework  established  by  the  DoDI 
5000.2. 


33 


Prwrn  miry  it  Mitotan**  A,  9.  or  C 
En&ims*  *m»l»  mat  bffon  ml*nnfl  pftiMi 
EndutwwY  9f  Slnqfii  ESppI*  FiW 

Cuawy 


JQC 


FOC 


tyrati  SysiF- 

Irrip'ji  iliLrti  p*mert»li«1lgfl 

tin  Ml  FuMbB,  Prfrf 

IfiMijftod  |  MpteY1™"* 

SwUanuntnl 

b mm 

A  Coral* 

J  Btebn 

os- 

.■  \  Plufuil^n 

V 

Concipl 

Idl  tinning,' 

Mwelopfuenr 

E  inlEiti  DenridprTtfH 
&  Df“.-ViST  irf>i 

Pracujf  si  t  Mpi&vnwi! 

4  5v«KH1 

Pn-Syttomi 

faquWDon 


SytfHni  AjciMilton 


StjlUlftftMl 


OC  H4o4  (Xe<3«r4!  Cami^Tf 

to; 


Mini  C«pjbir<t*  OekT+Pc^wrl  C*»0#*tr  •Vpdwto* 

bMPl  I  Dututit™  >CCOi  ]  CuiuMri!  (CPU;- 


thibIIihi  ship  io  Tlcdi.  f  emtnis  Process 

Figure  5.  Defense  Acquisition  Management  Framework  from 

(DAU,  2005,  p.  49) 


Although  the  defense  acquisition  management  framework  was  designed  to  help 
manage  the  acquisition  of  complex  weapons  systems  rather  than  services  (as  defined  in 
Chapter  II),  the  basic  management  precepts  can  still  be  applied  to  SOA.  The  primary 
service  delivery  lifecycle  stages  when  implementing  an  SOA  are  services-oriented 
analysis,  service  modeling,  services-oriented  design,  service  development,  and  service 
implementation  (Erl,  2008b,  p.  77).  The  acquisition  of  services  can  follow  the  basic 
outline  of  the  defense  acquisition  management  framework.  The  services-oriented 
analysis  and  modeling  phases  can  be  incorporated  into  the  concept  refinement  phase; 
whereas,  the  services-oriented  design  phase  fits  into  the  technology  development  phase. 
Similarly,  the  service  development  phase  fits  within  the  system  development  and 
demonstration  phase,  and  the  service  implementation  phase  fits  within  the  production  and 
deployment  phase.  Once  the  service  or  services  enter  the  operations  and  support  phase, 
service  governance  phases  take  over.  The  concept  decision,  milestone  reviews,  design 
readiness  review,  and  full-rate  production  decision  review  can  similarly  be  applied  to  an 
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SOA  as  it  progresses  through  the  service  delivery  lifecycle  stages.  The  service  delivery 
lifecycle  stages  of  an  SOA  do  not  completely  fit  within  the  defense  acquisitions 
management  framework;  however,  the  flexibility  of  the  framework  allows  MDAs  and 
Program  Managers  to  tailor  these  procedures  and  processes  to  meet  the  needs  of 
implementing  an  SOA. 

In  February  2008,  the  Secretary  of  the  Navy,  Donald  C.  Winter,  released  a  notice 
outlining  improvements  for  the  Navy’s  requirements  and  acquisition  process.  The 
purpose  of  this  document  is 

To  establish  a  review  process  to  improve  governance  and  insight  into  the 
development,  establishment,  and  execution  of  acquisition  programs  in  the 
Department  of  the  Navy  (DON).  The  goal  of  the  review  process  is  to 
ensure  alignment  between  Service-generated  capability  requirements  and 
acquisition,  as  well  as  improving  senior  leadership  decision-making 
through  better  understanding  of  risks  and  costs  throughout  a  program’s 
entire  development  cycle.  (Winter,  2008,  p.  2) 

The  new  process  integrates  a  two-pass  system  with  three  gate  reviews  per  pass 
into  the  acquisition  lifecycle.  The  notice  outlines  the  procedures  for  each  pass  and  its 
associated  review  gates  and  establishes  input  and  exit  criteria  for  each  gate,  as  well  as  the 
briefing  content  for  each  gate.  The  new  process  also  establishes  the  System  Design 
Specification  (SDS)  Development  Plan,  which  is  developed  either  during  the  Concept 
Refinement  Phase  or  Technology  Development  Phase,  depending  on  the  milestone  at 
which  the  program  is  initiated.  The  notice  also  establishes  gate  review  membership, 
which  includes  a  Chair,  Principal  Members  and  Advisory  Members.  The  process  flow  is 
outlined  for  programs  that  are  initiated  at  either  Milestone  A  or  Milestone  B,  as  seen  in 
Figures  6  and  7. 
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Figure  6.  DON  Requirements/Acquisition  Two-Pass/Six-Gate  Process  with 

Development  of  a  System  Design  Specification  (illustrated  example  for  program 

initiation  at  Milestone  A)  from 
(Winter,  2008,  p.  9) 
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Figure  7.  DON  Requirements/Acquisition  Two-Pass/Six-Gate  Process  with 

Development  of  a  System  Design  Specification  (illustrated  example  for  program 

initiation  at  Milestone  B)  from 
(Winter,  2008,  p.  10) 


As  seen  in  Figures  6  and  7,  this  new  process  adds  more  decision  reviews  into  a 
process  that  already  has  six.  While  the  addition  of  these  new  decision  review  gates  are 
meant  to  “establish  a  disciplined  and  integrated  process”  to  be  “implemented  in  an 
integrated,  collaborative  environment,”  the  amount  of  time  and  effort  managing  this 
decision  review  process  becomes  increasingly  time-consuming  and  complex.  The  main 
purpose  behind  the  defense  acquisition  management  framework  established  in  the  DoDI 
5000.2  is  to  provide  a  simple  and  flexible  management  process.  The  addition  of  these 
new  review  passes  and  gates  is  contrary  to  the  concepts  of  the  defense  acquisition 
management  framework.  The  addition  of  the  SDS  Development  Plan  also  adds  time  and 
complexity.  The  development  of  the  SDS  duplicates  many  of  the  requirements  that  are 
already  covered  in  the  Initial  Capabilities  Document  (ICD)  and  the  Capability 


37 


Development  Document  (CDD).  Adding  more  review  processes  and  documentation 
requirements  will  not  be  conducive  to  fielding  systems  that  respond  rapidly  to  changes  in 
requirements  and  technology  advances. 

2.  Integrated  Architectures 

The  DoDI  5000.2  requires  all  “DoD  components  to  develop  joint  integrated 
architectures  for  capability  areas  as  agreed  by  the  Joint  Staff’  (Under  Secretary  of 
Defense  (AT&L),  2003b,  p.  3).  IWS  that  use  SOA  and  OA  fall  under  the  requirement  for 
development  as  joint  integrated  architectures.  These  systems  must  be  interoperable  with 
the  Global  Information  Grid  (GIG)  architecture  and  must  be  developed  in  accordance 
with  the  Joint  Technical  Architecture.  The  Navy  must  address  impacts  of  using  systems 
that  take  advantage  of  SOA  and  OA  and  detennine  the  impact  they  have  on  the  GIG  and 
other  joint  systems.  Interoperability  is  not  only  required  within  new  systems  the  Navy 
develops,  it  is  also  imperative  that  new  systems  continue  to  enhance  joint  capabilities. 
During  requirements  and  capabilities  development,  each  military  department  and  the 
related  defense  agencies  are  required  to  participate  to  ensure  new  systems  enhance 
interoperability. 

3.  Evolutionary  Acquisition 

“Evolutionary  acquisition  is  the  preferred  DoD  strategy  for  rapid  acquisition  of 
mature  technology  for  the  user”  (Under  Secretary  of  Defense  (AT&L),  2003b,  p.  4).  This 
acquisition  method  is  intended  for  mature  technologies  that  have  proven  benefits  that  can 
be  quickly  applied  to  improve  military  capabilities.  Evolutionary  acquisition  relies  upon 
updating  requirements  continuously  to  develop  the  most  useful  systems  for  users.  Figure 
8  depicts  the  evolutionary  acquisition  strategy.  This  figure  illustrates  program  initiation 
and  the  process  through  the  evolutionary  acquisition  cycle.  Feedback  loops  provide 
updated  requirements  and  refine  concepts  as  the  program  continues  toward  completion. 
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Figure  8.  Requirements  and  the  Acquisition  Process  from 
(Under  Secretary  of  Defense  (AT&L),  2003b,  p.  4) 


There  are  two  approaches  to  evolutionary  acquisition,  and  a  program  may  elect  to 
use  either.  These  approaches  are  spiral  development  and  incremental  development. 


a.  Spiral  Development 

Spiral  development  is  the  preferred  development  method  for  DoD 
acquisition  programs. 


In  this  process,  a  desired  capability  is  identified,  but  the  end-state 
requirements  are  not  known  a  program  initiation.  Those  requirements  are 
refined  through  demonstration  and  risk  management;  there  is  continuous 
user  feedback;  and  each  increment  provides  the  user  the  best  possible 
capability.  The  requirements  for  future  increments  depend  on  feedback 
from  users  and  technology  maturation.  (Under  Secretary  of  Defense 
(AT&L),  2003b,  p.  4) 
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b.  Incremental  Development 


Although  incremental  development  is  not  the  preferred  acquisition 
method,  it  is  acceptable  to  use  for  programs  that  are  not  conducive  to  spiral  development. 
“In  this  process,  a  desired  capability  is  identified,  an  end-state  is  known,  and  that 
requirement  is  met  over  time  by  developing  several  increments,  each  dependent  on 
available  mature  technology”  (Under  Secretary  of  Defense  (AT&L),  2003b,  p.  5). 

c.  Combined  Development 

SO  A  and  OA  are  relatively  new  technologies  within  the  DoD.  To 
properly  employ  and  mitigate  risks  with  early  SOA  and  OA  development  and 
implementation  into  Navy  programs,  both  spiral  and  incremental  development  should  be 
considered.  Some  requirements  for  IWS  are  well  known  and  are  unlikely  to  change  in 
the  near  future;  these  programs  would  benefit  from  more  traditional  incremental 
development  methods.  As  IWS  systems  mature  to  address  emerging  and  future  threats, 
many  requirements  are  unknown  and  known  requirements  are  likely  to  change  to  adapt  to 
these  threats;  these  systems  will  benefit  better  from  spiral  development. 

SOA  is  a  prime  candidate  for  systems  requiring  innovative  technology  in  a 
highly  dynamic  environment.  SOA  provides  the  agility  to  rapidly  adapt  systems  as 
requirements  are  updated  and  new  requirements  are  realized.  OA  enhances  SOA’s  ability 
to  adapt  more  rapidly  due  to  OA’s  alleviation  of  proprietary  hardware  and  software. 

4.  Technology  Opportunities 

Rapid  advances  in  technology  and,  more  specifically,  in  software  and  network 
architectures  provide  opportunities  for  the  Navy  to  enhance  and  expand  IWS  capabilities. 
SOA  and  OA  are  relatively  new  technological  concepts  that  will  allow  Navy  IWS  to 
adapt  rapidly  as  new  requirements  emerge.  Interoperable  systems  requiring 
modifications  will  continue  to  expand  as  technology  allows  for  improved  networking. 
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The  DoDI  5000.2  requires  technologists  and  industry  to  seek  new  technology 
opportunities  to  facilitate  future  capabilities.  SO  A  and  OA  are  two  opportunities  to 
improve  future  capabilities.  Developing  an  SOA  does  not  require  using  open 
architectures  and  Navy  IWS  will  benefit  from  using  SOA  alone.  Using  “an  open,  or  at 
least  elegant,  architecture  is  key  to  fonning  a  basis  for  independent  modular  variety:  and 
through  design  specification  and  configuration  management  accountability  is  essential  for 
managing  the  complexity  of  multiple  product  releases”  (Dillard  &  Ford,  2007,  p.  494).  In 
case  studies  by  Dillard  and  Ford,  the  advantages  of  using  OA  as  the  basis  for 
architectures  shows  significant  reduction  in  product  cycle -time  when  using  incremental 
or  spiral  development.  OA  complements  SOA  by  improving  modularity  and  reducing 
vendor  specific  product  requirements.  During  spiral  development,  requirements  are 
continuously  updated  to  better  meet  user  needs.  Using  OA  to  develop  SOAs  may  provide 
the  flexibility  for  more  rapid  changes  to  requirements  during  spiral  or  incremental 
development.  Composable  systems  can  reap  the  benefits  of  OA  and  SOA  since  these 
technologies  provide  the  modularity  for  interoperability  across  multiple  platforms. 

5.  Summary 

The  DoDD  5000.1  and  DoDI  5000.2  include  the  guidelines  for  developing  and 
acquiring  emerging  technologies  such  as  SOA  and  OA.  The  DoD  has  realized  the  need 
for  systems  that  meet  needs  of  multiple  platforms  and  that  are  capable  of  adapting  to 
meet  new  threats.  Reducing  product  cycle-times  is  imperative  and  Naval  IT  programs 
can  no  longer  remain  in  a  3-  to  5 -year  development  cycle.  Once  established,  OA  and 
SOA  will  provide  the  foundation  for  more  rapid  modifications.  These  technologies  will 
also  lead  to  reduced  costs,  as  composable  systems  become  common  in  Navy  IWS.  The 
current  acquisition  system  presently  mandates  OA  to  be  considered  when  developing  new 
systems.  SOA  provides  the  technology  opportunities  and  capabilities  that  the  directives 
and  instructions  require  managers  to  consider.  For  example,  much  of  the  current  effort  in 
the  surface  domain  is  to  transition  the  major  combat  systems  to  OA  and  to  use  the 
components  to  provide  the  basis  for  the  new  (CGX)  combat  system  (Benedict,  2008,  p. 
2). 
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D.  JOINT  CAPABILITIES  INTEGRATION  AND  DEVELOPMENT  SYSTEM 


As  stated  previously  in  the  introduction  to  this  chapter,  SOA  and  OA  have 
impacts  within  the  Defense  Acquisition  System,  JCIDS,  and  PPBE  decision  support 
systems.  This  section  will  highlight  some  of  the  impacts  that  SOA  and  OA  may  have  on 
the  JCIDS  process. 

The  JCIDS  process  “involves  an  analysis  of  Doctrine,  Organization,  Training, 
Material,  Leadership  and  Education,  Personnel  and  Facilities  (DOTMLPF)  in  an 
integrated,  collaborative  process  to  define  gaps  in  warfighting  capabilities  and  propose 
solutions”  (DAU,  2005,  p.  39).  As  the  DoD  continually  gravitates  towards  more  joint 
warfighting  capabilities,  the  “gaps”  between  legacy  systems  become  more  and  more 
apparent.  The  lack  of  interoperability  between  legacy  systems  acquired  through 
traditional  “stove-piped”  acquisition  processes  requires  defense  leadership  to  examine 
and  analyze  solutions  that  promote  increased  interoperability  through  the  JCIDS  process. 
The  implementation  of  SOA  and  OA  into  future  combat  systems  through  the  JCIDS 
process  enables  increased  interoperability  and  promotes  joint  warfighting  concepts.  The 
JCIDS  link  to  the  Defense  Acquisition  System,  as  seen  in  Figure  9,  provides  the  required 
analysis  of  the  interoperability  and  integrated  architectures  of  a  defense  acquisition 
program  as  it  progresses  through  its  acquisition  lifecycle.  The  JCIDS  process  provides  a 
top-down  approach  to  detennining  essential  warfighting  capabilities.  The  top-down 
approach  incorporates  meaningful  levels  of  analysis  across  the  enterprise.  To  implement 
an  SOA,  a  top-down  approach  is  needed  to  emphasize  the  relationship  between  the 
business  processes  of  the  enterprise  and  the  services  that  represent  and  implement  the 
business  logic  (Erl,  2008b,  p.  78). 
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DoD  Strategic  Guidance 
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Figure  9.  JCIDS  Link  to  Defense  Acquisition  from 

(DAU,  2005,  p.  41) 


During  the  JCIDS  process,  the  Initial  Capabilities  Document  (ICD)  is  developed 
and  “provides  the  definition  of  the  capability  need  and  where  it  fits  in  the  broader 
concepts  and  architectures”  (DAU,  2005,  p.  40).  Again,  the  ICD  provides  the  top-down 
analysis  approach  needed  to  ensure  that  the  services-orientation  is  applied  to  the  required 
capabilities  of  the  enterprise.  The  Capabilities  Development  Document  (CDD)  and  the 
Capability  Production  Document  (CPD)  provide  the  Key  Performance  Parameters  (KPP), 
which  are  the  “attributes  or  performance  characteristics  considered  most  essential  for  an 
effective  military  capability”  (p.  40).  The  utilization  of  SOA  and  OA  should  be  reflected 
in  the  KPPs. 
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E.  CONTRACTING  PROCESS 

Rendon’s  Naval  Postgraduate  School  research,  Using  A  Modular  Open  Systems 
Approach  in  Defense  Acquisitions:  Implications  for  the  Contracting  Process,  explored 
the  use  of  the  modular  open  systems  approach  (MOSA)  as  a  method  for  implementing  an 
evolutionary  acquisition  strategy  and  the  implications  it  had  on  the  contracting  process 
(2006,  p.  1).  As  stated  earlier  in  this  chapter,  a  MOSA  supports  many  principles  and 
benefits  that  are  consistent  with  SOAs  and  OAs;  therefore,  Rendon’s  assertions  of  the 
implications  of  a  MOSA  on  the  contracting  process  can  be  applied  to  SOA  and  OA.  In 
his  research,  Rendon  states: 

The  program  acquisition  strategy  should  describe  agency  needs  and 
objectives  using  mission-related  or  perfonnance-based  tenns.  In  addition, 
the  contracting  strategy  should  flow  from  the  acquisition  strategy,  and 
both  should  be  consistent  in  goals  and  objectives.  An  acquisition  strategy 
using  a  modular  open  systems  approach  should  be  focused  on  critical 
areas  such  as  adopting  evolving  requirements,  promoting  technology 
transfer,  facilitating  system  integration,  leveraging  commercial 
investment,  reducing  cycle-time  and  lifecycle  cost,  ensuring 
interoperability,  enhancing  commonality  and  reuse,  enhancing  access  to 
cutting  edge  technologies  and  products  from  multiple  suppliers,  mitigating 
technology  obsolescence  risk,  mitigating  single  source  of  supply  risk, 
enhancing  lifecycle  supportability,  and  increasing  competition.  (Rendon, 

2006,  p.  29) 

Similar  to  using  a  MOSA  contracting  strategy,  the  contracting  strategy  supporting 
an  SOA-  or  OA-based  acquisition  strategy  should  be  structured  to  achieve  these  MOSA 
objectives,  which  are  consistent  with  many  of  the  SOA  and  OA  objectives. 

Rendon’s  research  further  shows  that  “the  solicitation  for  an  acquisition  program 
using  an  open  systems  approach  will  require  specific  language  unique  to  the  use  of  a 
modular  open  systems  approach.  Thus,  the  procurement  documents  that  make  up  the 
solicitation  should  incorporate  the  specific  language  that  reflects  the  preference  or 
mandated  use  of  a  modular  open  systems  approach  in  the  acquisition  program”  (Rendon, 
2006,  p.  36).  Similar  to  a  MOSA  approach,  solicitation  for  an  acquisition  using  an  SOA- 
or  OA-based  approach  will  require  specific  language  that  is  unique  to  the  use  of  SOA  or 


44 


OA.  Additionally,  the  procurement  documents  will  require  specific  language  that  reflects 
the  use  of  an  SOA-  or  OA-based  approach  in  the  acquisition  program. 

Rendon’s  research  also  states  that  “in  acquisition  programs  using  a  modular  open 
systems  approach,  the  government  will  want  to  incentivize  the  contractor  to  meet  higher 
levels  of  “openness”  in  the  design  and  development  of  the  system”  (2006,  p.  57).  For 
programs  that  intend  to  implement  SOA  and  OA,  program  managers  and  contracting 
officers  will  need  to  develop  an  acquisition  strategy  and  a  contracting  strategy  that 
provides  incentives  to  contractors  to  utilize  SOA  and  OA  principles  and  practices  to 
achieve  the  high  levels  of  “openness”  desired  for  future  IWS. 

Having  realized  the  importance  of  the  contracting  process  when  acquiring  and 
fielding  systems  that  incorporate  OA,  the  PEO-IWS  developed  an  OA  contracting 
guidebook  for  program  managers.  The  Naval  Open  Architecture  Contract  Guidebook 
was  developed  to  “provide  Program  Managers,  Contracting  Officers,  and  their  supporting 
organizations  with  guidance  and  example  contract  language  to  assist  them  in 
incorporating  Open  Architecture  principles  into  their  contracts”  (PEO-IWS  7,  2007,  p.  1). 
Similarly,  the  Navy  will  need  to  develop  a  contracting  guidebook  for  implementing  SOA 
to  provide  program  managers  and  contracting  officers  guidance  for  incorporating  SOA 
principles  into  their  contracts. 

F.  NOA  AND  SOA  POLICY  GUIDANCE 

The  purpose  of  this  section  is  to  review  the  current  NOA  policy  guidance  and  to 
review  how  the  Navy  is  developing  its  SOA  guidance.  As  stated  in  the  previous  chapter, 
in  the  OA  section,  the  NOA  policy  guidance  is  set  forth  in  several  DoD  and  Navy  policy 
documents.  In  January  2006,  CAPT  James  J.  Shannon,  Naval  Open  Architecture  Program 
Manager,  PEO-IWS  7.0,  developed  a  brief  delineating  what  program  managers  need  to 
know  about  NOA.  In  that  brief,  he  highlighted  the  major  documents  that  help  establish 
NOA  policy  guidance.  The  DoDD  5000.1  and  the  use  of  Modular  Open  Systems 
Approach  (MOSA)  were  discussed  earlier  in  this  chapter.  The  following  sections  will 
cover  the  remaining  policy  guidance  concerning  NOA,  adapted  from  Shannon’s  brief. 
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1. 


NOA  Scope  and  Responsibilities 


The  August  5,  2004,  Assistant  Secretary  of  the  Navy  (Research,  Development  & 
Acquisition)  Policy  Statement,  entitled  Naval  Open  Architecture  Scope  and 
Responsibilities,  assigns  responsibility  and  authority  for  directing  the  NOA  effort  to  the 
Program  Executive  Officer  (PEO)  Integrated  Warfare  Systems  (IWS)  and  establishes  the 
OA  Enterprise  Team  (OAET),  which  is  to  be  chartered  and  led  by  PEO-IWS.  It  further 
states  that  the  “OAET  shall  be  responsible  to  defining  an  overarching  OA  acquisition 
strategy  and  develop  guidance  addressing  incentives,  intellectual  property  issues, 
contracting  strategies  and  funding  alternatives”  (as  cited  in  Shannon,  2006,  January,  p.  6). 
It  also  states  that  the  OAET  “shall  prepare,  staff,  and  promulgate  a  Navy-wide  OA 
business  strategy”  (p.  6).  Additional  OAET  roles  and  responsibilities  outlined  in  the 
ASN(RD&A)’s  memo  are  below: 

•  Lead  the  Navy  Enterprise  to  OA  implementation 

•  Provide  OA  Systems  Engineering  leadership  to  PEO’s,  industry 
partners,  Joint  Organizations,  Navy  Warfare  Centers  and  other 
participating  organizations 

•  Provide  the  forum  and  process  by  which  cross  domain  OA 
proposals  and  solutions  are  utilized  across  domains 

•  Identify  cross-domain  components  and  opportunities  for  cost 
reduction  and  reuse 

•  Leverage  technical,  business,  and  organizational  solutions  from  all 
participating  communities 

•  Establish  an  advisory  team,  comprised  of  industry  and  academia, 
to  interpret  and  advise  the  team  on  an  as  periodic  basis  (p.  7) 

2.  Memorandum  of  Understanding 

The  December  3,  2004,  Memorandum  of  Understanding  (MOU)  among  PEO- 
IWS,  PEO  SUBS,  PEO  (T),  PEO  C4I,  and  PEO  Space  Systems  made  the  OAET 
responsible  for  the  OA  effort  across  the  Naval  Enterprise,  including  ensuring 
implementation  confonns  to  MOSA  policy  and  requirements,  ensuring  that  OA  progress 
assessments  comply  with  the  Program  Assessment  Review  Tool  (PART),  and  promoting 
NOA  Enterprise  products  to  OSD,  DoD  agencies  and  other  Service  components  (as  cited 
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in  Shannon,  2006,  January,  p.  8).  The  MOU  is  under  revision  at  present,  and  will  expand 
the  participation  to  include  additional  PEOs,  OPNAV  codes  and  SYSCOM  technical 
authorities  (Wessman,  2008). 

3.  OA  EXCOMM  Action  Items 

The  15  May  2005  ASN(RD&A)  Memorandum  summarizing  OA  EXCOMM  III 
of  February  22,  2005,  required  ACAT  I  programs  to  use  the  OA  Assessment  Model 
(OAAM)  to  detennine  the  “as-is”  level  of  openness  and  desired  “to-be”  state  and  to 
produce  metrics  and  conduct  business  case  analyses  if  necessary  (as  cited  in  Shannon, 
2006,  January,  p.  11).  As  stated  in  the  previous  chapter  in  the  OA  section,  the  OA 
assessment  model  and  an  assessment  tool  were  developed  to  help  program  managers 
evaluate  the  “openness”  of  their  respective  program  or  system. 

4.  OPNAV  Requirements 

The  December  23,  2005,  Deputy  Chief  of  Naval  Operations  (Warfare 
Requirements  and  Program)  (N6/N7)  Requirement  for  Open  Architecture  (OA) 
Implementation  “established  the  requirement  to  implement  Open  Architecture  (OA) 
principles  across  the  Navy  Enterprise”  (as  cited  in  Shannon,  2006,  January,  p.  15).  It  also 
established  the  OA  Council  (OAC)  of  representatives  of  N6/N7  Division  Directors  to 
work  with  the  OAET  on  the  requirements  set  forth  in  the  ASN(RD&A)’s  August  5,  2004 
Memorandum.  The  letter  also  directs  the  OAC,  PEO-IWS  7.0,  and  the  OAET  to  focus 
assessment  priorities  in  support  of  the  following  capabilities:  track  management,  combat 
identification  (CID),  data  fusion,  time-critical  targeting  and  strike,  and  integrated  fire 
control  (p.  15). 


5.  NOA  Policy  and  Guidance  Summary 

Over  the  last  several  years,  the  Navy  has  spent  considerable  time  and  effort 
developing  its  NOA  policies  and  guidance  to  best  implement  open  architecture  into 
acquisition  strategies.  The  policies  discussed  previously  have  set  the  foundation  the 
Navy  needs  to  successfully  implement  OA.  The  Navy  has  also  developed  guidance 
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documents  to  help  program  managers  implement  OA  into  their  respective  programs, 
which  includes  the  NOA  Contract  Guidebook.  The  Navy  has  also  developed  the  NOA 
website  that  contains  all  the  information  concerning  NOA.  In  short,  the  Navy’s  policies 
and  guidance  concerning  OA  have  begun  to  catch  up  with  the  commercial  market  and 
should  facilitate  the  implementation  of  OA  into  future  combat  systems  acquisition 
processes. 


6.  SOA  Policy  and  Guidance 

In  April  2006,  the  Navy’s  Chief  Information  Office  (CIO)  chartered  the 
Department  of  Navy  (DON)  SOA  Transformation  Group  (Wennergren,  2006).  The  DON 
SOA  Transformation  Group 

will  provide  the  direction  for  Commands  to  align  to  a  DON  Net-Centric, 
interoperable  environment,  based  on  a  Service-Oriented  Architecture 
ensuring  all  services  are  visible,  trusted,  accessible  and  usable-when 
needed  and  where  needed-to  accelerate  the  decision  cycle  process 
throughout  the  DON  WarFighter  community,  via  web-centric  technology. 
(Wennergren,  2006,  p.  1) 

Similar  to  the  OAET,  the  DON  SOA  Transformation  Group  is  responsible  for 
developing  a  DON  SOA  policy,  a  DON  SOA  Concept  of  Operations  (CONOPS), 
metrics,  and  Return  on  Investment  (ROI)  models.  They  will  also  be  responsible  for 
developing  white  papers  that  will  include  best  practices  for  implementing  SOA, 
acquisition  strategy  recommendations  for  implementing  SOA  and  certification  and 
accreditation  policies  (p.  2). 

Although  the  DON  SOA  Transformation  Group  has  yet  to  deliver  any  official 
policies  or  guidance  concerning  the  implementation  strategy  the  Navy  will  utilize  with 
regards  to  SOA,  the  ball  is  at  least  rolling  in  the  right  direction.  The  Navy’s  promotion  of 
SOA,  along  with  its  policies  and  guidance  for  implementing  OA,  are  beginning  to 
prepare  the  Navy  for  new  business  and  technology  trends  that  will  impact  the  acquisition 
of  future  combat  systems. 
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G. 


OTHER  FACTORS 


1.  Horizontal  Systems  Engineering 

In  December  2004,  The  Assistant  Secretary  of  the  Navy,  John  J.  Young,  Jr., 
released  a  memorandum  stating  the  need  for  cross-platfonn  commonality  with 
engineering  systems.  The  current  vertical  management  of  acquisition  programs 
complicates  cross-platform  commonality,  since  decisions  are  delegated  to  prime 
contractors.  The  prime  contractors  limit  system  modularity  by  optimizing  “their 
particular  business  models  rather  than  ours”  (Young,  2004,  December  23,  p.  1).  Young 
recognizes  the  need  for  Executive  Committees  (EXCOMM)  to  promote  cross-platform 
commonality  by  developing  “action  paths”  that  lead  to  horizontal  systems  integration 
across  multiple  platforms.  “The  product  of  these  EXCOMMs  will  be  recommendations 
and  action  assignments  for  my  signature  to  develop  architectures,  roadmaps  and 
implementation  plans  to  increase  commonality”  (p.  1).  The  result  of  the 

recommendations  will  lead  to  enterprise-wide  commonality  in  hardware  and  software. 

SOA  combined  with  OA  provides  the  mechanisms  for  initiating  horizontal 
integration  for  IWS  through  hardware  and  software  based  on  OAs  and  SOAs.  OA 
mitigates  risks  associated  with  prime  contractors  utilizing  proprietary  software  and 
hardware  to  optimize  their  business  models  and  creates  flexibility  for  the  Navy  when 
integrating  systems  across  multiple  platforms.  SOA  allows  for  increased  modularity  and 
interoperability  in  IWS  that  require  common  capabilities  but  have  varying  mission 
requirements.  SOA  combined  with  OA  supports  horizontal  systems  engineering  and 
provides  a  path  for  the  transition  from  a  vertical  acquisition  to  horizontal  acquisition 
process. 

2.  PEO-IWS 

The  PEO-IWS  vision  states:  “PEO  IWS  leads  a  professional  and  experienced 
organization  that  delivers  Enterprise  solutions  for  Naval  warfare  systems  that  operate 
seamlessly  and  effectively  within  the  Fleet  and  Joint  Force”  (Department  of  the  Navy, 
2008).  The  PEO-IWS  is  intended  to  facilitate  the  transfonnation  of  the  acquisition 
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process  from  the  current  vertical  process  to  a  more  horizontal  process.  Jesse  M.  Mink’s 
Naval  Postgraduate  School  thesis,  Analysis  of  Horizontal  Integration  within  the  Program 
Executive  Office,  Integrated  Warfare  Systems,  suggests  barriers  exist  that  prevents  PEO- 
IWS  from  facilitating  its  mission.  The  following  excerpt  from  Mink’s  thesis  states  the 
PEO-IWS  function. 

PEO  IWS  was  founded  to  oversee  design,  construction,  and  maintenance 
of  all  surface  ship  and  submarine  combat  systems.  The  stated  intent  of  this 
re-organization  was  to  shift  from  a  platform-centered  approach  to  a  more 
integrated  consistent  approach  across  all  combat  systems.  PEO  IWS  is  the 
entity  charged  with  coordinating  the  integration  of  warfare  systems  into  a 
single,  functioning  system  of  systems  that  can  then  be  integrated  onto  any 
platform.  Integration  of  the  warfare  system  and  the  ship  itself  requires 
hannonization  and  communication  between  and  across  PEO  IWS  and  its 
stakeholders.  (Mink,  2006,  p.  22) 

Although  the  PEO-IWS  plays  an  integral  part  when  deciding  what  new  IWS 
should  be  developed  for  the  Navy’s  ships,  the  funding  is  distributed  to  other  PEOs  such 
as  PEO  Carriers  or  PEO  Ships.  This  funding  structure  does  not  provide  the  flexibility 
necessary  for  PEO-IWS  to  horizontally  integrate  common  systems  into  various  platforms. 
Distributing  the  funding  for  IWS  directly  to  PEO-IWS  would  alleviate  the  problems  with 
disparately  acquired  systems  that  reduce  interoperability.  Providing  interoperable 
systems  by  managing  common  systems  acquisition  programs  from  a  single  PEO  can  lead 
to  more  rapid  acquisition,  increased  interoperability,  and  cost  reductions.  The  PEO-IWS 
must  not  only  be  involved  in  the  acquisition  process  for  IWS  but  must  also  be  responsible 
for  maintenance  actions  that  require  system  changes.  Managing  IWS  for  all  ships  will 
reduce  interoperability  issues  arising  from  changes  to  one  platfonn  and  the  effects  the 
changes  will  have  on  other  platforms.  As  SOA-  and  OA-based  IWS  are  horizontally 
integrated  on  naval  platforms,  system  modifications  overseen  by  PEO-IWS  will  provide 
rapid  systems  changes  and  ensure  the  systems  remain  interoperable  to  enhance  warfighter 
capabilities. 

3.  Information  Technology  Portfolio  Management 

In  October  2005,  the  Acting  Deputy  Secretary  of  Defense,  Gordon  England, 
issued  a  DoD  Directive  that  “establishes  policy  and  assigns  responsibility  for  the 
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management  of  DoD  information  technology  (IT)  investments  as  portfolios  that  focus  on 
improving  DoD  capabilities  and  mission  outcomes”  (Assistant  Secretary  of  Defense 
(NII/DoD  CIO),  2005,  p.  1).  The  policy  further  states  that  “IT  investments  shall  be 
managed  as  portfolios  to:  ensure  IT  investments  support  the  Department’s  vision, 
mission,  and  goals;  ensure  efficient  and  effective  delivery  of  capabilities  to  the 
warfighter;  and  maximize  return  on  investment  to  the  Enterprise”  (Assistant  Secretary  of 
Defense  (NII/DoD  CIO),  2005,  p.  2). 

In  the  article  “Best  practices  for  Building  SOA  Applications,”  seven  steps  to  SOA 
adoption  are  identified.  One  of  the  key  steps  to  effective  SOA  adoption  is  to  create  a 
portfolio  of  services  (SYS-CON  Media  Inc.,  2008,  p.  2).  As  stated  before,  an  SOA 
models  the  business  or  enterprise  as  a  collection  of  self-contained  services,  which  are 
implementations  of  a  well-defined  piece  of  business  functionality.  In  the  DoD,  a  well- 
defined  piece  of  business  functionality  can  be  viewed  as  a  capability.  DoD  Instruction 
81 15.02  states  “managing  portfolios  of  capabilities  aligns  IT  with  the  overall  needs  of  the 
warfighter,  as  well  as  the  intelligence  and  business  activities  which  support  the 
warfighter”  (Assistant  Secretary  of  Defense  (NII/DoD  CIO),  2006,  p.  3).  By 
implementing  an  SOA,  the  DoD  can  better  manage  its  IT  investments  as  a  portfolio  of 
services  that  implement  well-defined  pieces  of  business  functionality  (capabilities)  that 
support  the  Enterprise’s  vision,  mission  and  goals  while  ensuring  efficient  and  effective 
delivery  of  capabilities  to  the  warfighter. 

DoDI  81 15.02  also  states  that  IT  portfolio  management 

is  a  key  enabler  of  information  sharing.  In  accordance  with  DoD 
Directive  8320.2  (Reference  (m)),  portfolio  management  enables  data 
sharing  across  Components,  supports  cross-Component  communities  of 
interest,  and  ensures  data  sharing  agreements  are  implemented  by  the 
respective  Components.  These  activities  should  maximize  return  on 
investment  for  the  enterprise  by  reusing  accessible  data  rather  than 
recreating  existing  data.  (Assistant  Secretary  of  Defense  (NII/DoD  CIO), 

2006,  p.  5) 

One  of  the  key  tenets  of  an  SOA  is  re-use.  By  managing  an  SOA  as  a  portfolio  of 
services,  different  components  within  the  Enterprise  can  leverage  services  developed  by 
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other  components,  alleviating  redundant  capabilities  while  maximizing  return  on 
investment  for  the  entire  Enterprise.  Utilization  of  an  SOA  within  the  Navy  and  the  rest 
of  the  DoD  will  help  facilitate  the  management  of  IT  investments  as  portfolios. 

H.  SUMMARY 

This  chapter  discussed  the  current  Defense  Acquisition  System,  analyzed  how 
SOA  and  OA  can  be  integrated  into  the  current  processes  and  addressed  the  current  NOA 
policies  and  the  Navy’s  future  roadmap  for  SOA  policies.  It  also  discussed  other  factors 
affecting  the  implementation  of  SOA  and  OA,  with  regards  to  Horizontal  Systems 
Engineering,  the  current  PEO-IWS  structure  and  IT  portfolio  management.  The  main 
focus  of  this  chapter  was  to  answer  the  first  thesis  question:  “Does  the  Defense 
Acquisition  System  need  to  be  altered  to  take  advantage  of  SOA  and  OA  implementation 
into  the  acquisition  lifecycle?” 
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IV.  CASE  STUDY 


A.  INTRODUCTION 

The  previous  chapter  discussed  the  impacts  of  SOA  and  OA  within  the  Defense 
Acquisition  System.  The  focus  of  this  chapter  is  to  analyze  the  Navy’s  SOA 
implementation  within  the  Consolidated  Afloat  Networks  and  Enterprise  Services 
(CANES).  The  first  section  gives  a  broad  overview  of  CANES  and  what  it  is  trying  to 
accomplish.  The  next  section  will  discusses  how  the  Navy  plans  to  implement  SOA 
within  CANES  and  how  it  adheres  to  SOA  and  OA  principles  and  practices.  The 
following  section  will  discuss  how  CANES  will  utilize  SOA  and  OA  to  provide  future 
IWS  capabilities.  This  chapter  and  this  case  study  will  provide  answers  to  the  second  and 
third  thesis  questions,  “Do  current  Navy  OA  policies  and  SOA  practices  provide  the 
necessary  interoperability  requirements  for  future  IWS?”  and  “What  benefits  might  SOA 
and  OA  provide  to  IWS?” 

B.  CANES  OVERVIEW 

Currently,  there  are  a  multitude  of  legacy  standalone  afloat  networks  throughout 
the  Navy.  These  legacy  standalone  systems  were  developed  and  fielded  by  multiple 
acquisition  programs  and  program  offices  throughout  the  Navy.  These  legacy  network 
systems  represent  the  “stove-piped”  acquisition  strategies  of  the  past.  In  order  to  move 
forward  and  eliminate  these  “stove-pipes,”  the  Navy  implemented  CANES  as  an 
integrated  approach  to  consolidate  and  reduce  the  number  of  afloat  networks.  Figure  10 
depicts  how  CANES  intends  to  consolidate  the  legacy  afloat  networks. 
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C4I  Afloat  Networks  and  Enterprise 
Services  (CANES)  Roadmap 


Figure  10.  CANES  Roadmap  from  (SPAWAR,  2007a,  p.  2) 

The  Navy’s  vision  for  CANES  was  developed  based  on  “an  overarching  concept 
to  reduce  the  number  of  afloat  networks,  providing  efficiency  through  a  single 
engineering  focus  on  technical  solutions”  (SPAWAR,  2007a,  p.  1).  This  reduction  of 
networks  “allows  for  streamlining  acquisition,  contracting,  and  test  events,  and 
efficiencies  in  the  reduction  of  multiple  Configuration  Management  (CM)  baselines, 
logistics  and  training  “tails”  into  a  unified  support  structure”  (p.  1).  In  order  to  achieve 
this,  the  CANES  vision  established  four  equally  important  goals 

Goal  1-Collapse  the  number  of  networks  in  the  current  N6  afloat  network 
portfolio  by  use  of  cross-domain  technologies. 

Goal  2-Reduce  the  infrastructure  footprint  and  associated  costs  for 
hardware  afloat. 
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Goal  3-Provide  capability  to  meet  current  and  projected  warfighter 
requirements. 

Goal  4-Extend  network  consolidation  goals  to  naval  programs  outside  the 
current  N6  afloat  network  portfolio,  (p.  1) 

These  goals  demonstrate  the  Navy’s  desire  to  eliminate  the  “stove-piped” 
acquisition  processes  of  the  past.  Consolidating  these  legacy  networks  allows  the  Navy 
to  reduce  infrastructure  and  provide  increased  capabilities  while  lowering  lifecycle  costs. 
In  order  to  integrate  the  legacy  network  systems,  the  CANES  program  will  implement  an 
infrastructure  that  supports  a  Services-oriented  Architecture  (SOA). 

C.  ADHERENCE  TO  SOA  AND  OA  PRINCIPLES  AND  PRACTICES 

CANES  development  is  predicated  upon  adhering  to  common  SOA  and  OA 
principles  and  practices.  SOA  and  OA  principles  and  practices  were  described 
previously  in  Chapter  II.  The  focus  of  the  second  thesis  question  is  current  Navy  OA 
policies  and  SOA  practices.  This  section  will  analyze  the  principles  and  practices 
CANES  is  following  and  determine  if  this  program  is  adhering  to  common  SOA  and  OA 
practices. 

A  significant  CANES  goal  is  to  utilize  SOA  and  OA  to  breakdown  the  current 
“stove-pipes”  and  replace  the  current  network  structure  with  a  more  interoperable  and 
adaptable  solution.  Figure  1 1  illustrates  a  high-level  depiction  of  the  current  network  that 
must  be  transformed  to  incorporate  an  SOA. 
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Figure  11.  Exchange  of  Information  Across  Multiple  Secure  Naval  Networks 

from  (SPA WAR,  2007b,  p.  4). 


1.  CANES  RFI 

The  Space  and  Naval  Warfare  Systems  Command  (SPAWAR),  the  Program 
Executive  Office-Command,  Control,  Communications,  Computers,  Intelligence  (PEO- 
C4I),  Networks,  Information  Assurance  (IA),  and  Enterprise  Services  Programs  Office 
(PMW  160)  distributed  a  Request  for  Information  (RFI)  to  obtain  information  for 
possible  development  of  the  CANES  system.  Within  the  RFI,  the  aforementioned 
organizations  list  five  CANES  key  objectives 

•  Increased  network  reliability  and  efficiency 

•  Interoperable,  distributable,  and  loosely  coupled 

•  A  tiered  model  of  service  interactions 

•  Improved  control  over  costs 

•  A  scalable  tiered  model  of  service  interactions  (SPAWAR,  2007b, 
P-4) 

Interoperability  is  an  increasing  concern  with  naval  networks.  The  Navy’s  future 
IWS  systems  must  be  interoperable  and  reliable.  Interoperability  is  the  biggest  benefit 
SO  A  provides.  SO  A  aims  to  reduce  interoperability  issues  and  therefore  increase  system 
reliability  among  naval  platforms.  The  CANES  system  is  based  on  SOA  and  OA 
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principles  that  promote  interoperability.  The  CANES  system  development  process  has 
realized  SOA,  based  on  open  standards,  can  provide  the  solution  to  increase 
interoperability  among  naval  platforms. 

The  loose  coupling  within  the  CANES  system  is  one  of  the  key  tenets  of  an  SOA. 
Loose  coupling  is  an  SOA  design  goal  to  reduce  the  dependency  between  services,  while 
still  providing  interoperability  within  a  system.  Although  loose  coupling  is  desired  in  an 
SOA,  interoperability  has  greater  importance.  Services  should  only  have  reduced 
dependency  to  a  degree  that  still  allows  interoperability  between  multiple  services  and 
across  multiple  applications. 

Transitioning  to  a  more  horizontal  acquisition  structure  will  provide  improved 
control  over  costs.  An  incremental  approach  should  be  adopted  when  implementing  an 
SOA.  CANES  is  planned  as  an  incremental  implementation  beginning  with  core  services 
and  incorporating  new  services  as  needed.  As  common  systems  are  implemented  across 
varying  platforms,  costs  should  be  reduced. 

The  Navy  requires  that  CANES  is  scalable.  SOA  is  intended  to  provide 
scalability  by  reducing  duplicative  service  implementations.  Current  systems  will  be 
replaced  with  systems  that  utilize  interoperable  core  services.  A  tiered  model  of  service 
interactions  will  standardize  the  CANES  system  by  using  common  interfaces.  “By 
adhering  to  standardized  interfaces,  systems  can  utilize  common  services  which  will 
reduce  the  cost  and  consolidate  the  maintenance  of  the  systems”  (SPAWAR,  2007b,  p.5). 

“Two  main  tenets  of  CANES  enterprise  service  architecture  are:  1)  an  adherence 
to  standards,  and  (2)  technology/vendor  neutrality”  (SPAWAR,  2007b,  p.  7).  Navy  OA 
policies  and  practices  promote  the  development  of  interoperable  and  reusable 
applications  through  common  standards  and  interfaces,  which  leads  to  open  competition 
and  technology  neutrality. 

The  CANES  RFI  is  a  positive  step  towards  developing  an  SOA  utilizing  OA 
practices  and  principles. 
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2. 


CANES  SOA  Reference  Architecture 


To  properly  implement  an  SOA,  CANES  is  using  the  OASIS  SOA  reference 
model.  The  OASIS  model  “is  an  abstract  framework  for  understanding  significant 
entities  and  relationships  between  them  within  a  service-oriented  environment,  and  for 
the  development  of  consistent  standards  or  specifications  supporting  that  environment” 
(MacKenzie  et  al.,  2006,  p.  1).  This  model  provides  the  necessary  framework  to  develop 
an  SOA  and  provides  an  abstract  reference  model  that  can  be  applied  to  SOA  regardless 
of  technology  implementation.  The  OASIS  reference  model  for  SOA’s  relationship  to 
other  system  work  is  depicted  in  Figure  12. 
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Figure  12.  How  the  Reference  Model  Relates  to  Other  Work  from 

(MacKenzie  et  al.,  2006,  p.  5) 


Utilizing  the  OASIS  reference  model  provides  CANES  the  flexibility  to  adapt  to 
emerging  needs  for  various  platforms.  Using  the  OASIS  reference  model  is  an  example 
of  how  the  Navy  is  following  industry  standards  for  accepted  SOA  practices. 

The  Reference  Model  (RM)  of  current  interest  is  an  abstract  framework 
for  understanding  significant  entities  and  relationships  between  them 
within  a  service-oriented  environment,  and  for  the  development  of 
consistent  standards  or  specifications  supporting  that  environment.  It  is 

58 


based  on  unifying  concepts  of  SOA  and  may  be  used  by  architects 
developing  specific  service-oriented  architectures  or  in  training  and 
explaining  the  SOA  paradigm.  A  reference  model  is  not  directly  tied  to 
any  standards,  technologies  or  other  concrete  implementation  details  (such 
as  "Web  Services").  Hence,  a  good  reference  model  provides  common 
semantics  that  can  be  used  unambiguously  across  and  between  different 
implementations.  (Nickull,  2006) 

The  CANES  SOA  reference  architecture  identifies  several  qualities  that  must  be 
addressed  in  the  implementation  of  the  CANES  services  infrastructure.  The  qualities 
addressed  by  the  CANES  SOA  reference  architecture  are 

•  Interoperability 

•  Quality  of  Service 

•  Loose  Coupling 

•  Service  Operations  Management 

•  Service  Lifecycle  Management 

•  Service  Metadata  Management 

•  SOA  Governance  (MITRE  Corporation,  2007,  p.  3-1) 

Chapter  II  of  this  thesis  outlined  several  of  the  basic  SOA  concepts  and  principles. 
The  qualities  outlined  in  the  CANES  SOA  reference  architecture  mirror  those  concepts 
and  principles. 

An  SOA  based  on  common  services  provides  seamless  interaction  with  new  and 
legacy  systems  regardless  of  platform  specific  characteristics.  “The  CANES  Services 
Infrastructure  must  integrate  disparate  application  environments”  (MITRE  Corporation, 
2007,  p.  3-1).  By  using  common  services  and  interfaces,  legacy  systems  can  become 
encapsulated  enabling  communication  between  disparate  environments,  which  increases 
interoperability. 

The  CANES  Services  Infrastructure  “must  ensure  the  delivery  of  acceptable 
levels  of  service  in  terms  of  security,  performance,  and  integrity”  (MITRE  Corporation, 
2007,  p.  3-1).  An  SOA  must  provide  different  priority  levels  to  data  flows  that  provide 
the  security  and  integrity  of  the  data  while  maintaining  the  necessary  flow  of  critical  data. 
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An  SOA  design  goal  is  to  reduce  the  dependency  between  services  while  still 
providing  interoperability  within  a  system  through  loosely  coupled  services.  The 
CANES  SOA  reference  architecture  identifies  the  importance  of  loose  coupling  as  “a 
core  SOA  design  principle  that  ensures  flexibility,  reusability,  and  resiliency  in  the  face 
of  dynamic  systems”  (MITRE  Corporation,  2007,  p.  3-2). 

The  CANES  SOA  reference  architecture  identifies  the  necessity  to  provide 
Service  Operations  Management,  Service  Lifecycle  Management,  and  Service  Metadata 
Management.  When  implementing  an  SOA,  services  are  defined  and  designed  as  a  piece 
of  business  functionality.  Similar  to  a  business,  an  SOA  must  provide  the  operations  and 
lifecycle  management  of  the  business  or  service  functionality.  Since  the  metadata  of  a 
service  describes  the  different  aspects  of  the  service  and  its  capabilities,  it  to  must  be 
managed  as  a  business  functionality. 

Governance  refers  to  the  application  of  processes  utilized  throughout  an 
organization  when  developing  an  SOA.  These  processes  govern  how  SOAs  are  designed, 
developed,  implemented  and  maintained,  which  ensures  confonnity  to  the  guiding 
architectural  principles  and  regulations  established  by  the  organization.  The  CANES 
SOA  reference  architecture  states  that  governance  policies  “should  be  defined  that  dictate 
or  provide  guidance  for  service  creation,  service  testing,  service  utilization,  service 
management,  and  service  versioning”  (MITRE  Corporation,  2007,  p.  3-6).  These 
governance  policies  will  help  ensure  that  CANES  utilizes  SOA  principles,  processes  and 
best  practices  throughout  its  development. 

D.  CANES  SOA  AND  OA  USE  TO  PROVIDE  FUTURE  IWS  CAPABILITY 

The  benefits  that  SOA  and  OA  provide  to  IWS  are  the  focus  of  the  third  thesis 
question.  This  section  will  identify  some  of  the  benefits  of  CANES  and  how  its 
development  can  help  provide  future  IWS  capabilities. 

1.  Joint  Interoperability 

While  CANES  is  a  Navy  system  that  is  being  developed  for  ships,  it  must  not 

only  be  interoperable  with  other  shipboard  network  system,  it  must  also  be  interoperable 
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with  joint  systems.  The  Army,  Air  Force,  and  the  Marine  Corps  are  developing  SOA- 
based  systems.  The  Navy  is  collaborating  with  the  other  services,  using  a  Multi-service 
SOA  consortium  (Figure  13),  to  ensure  standard  interfaces  and  specifications  are  utilized 
to  meet  joint  interoperability  requirements. 

Multi-Service  SOA  Consortium 
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Figure  13.  Multi-Service  SOA  Consortium  from 
(PEO-C4I,  2008,  p.  26) 


As  each  military  service  develops  SOA-  and  OA-based  systems,  it  is  critical  that 
common  standards  are  used.  Figure  14  depicts  the  interaction  of  each  military  service’s 
SOA  interactions.  “A  DoD/DNI  Enterprise  Services  Technical  Governance  Forum  is 
validating  a  set  of  common  standards,  specifications,  and  reference  implementations  to 
enable  joint  interoperability  across  a  multi-Service/Agency  SOA”  (PEO-C4I,  2008,  p. 
28).  As  each  military  service’s  particular  SOA  program  matures,  governance  is 
increasingly  important.  A  governance  organization  should  be  independent  from  any 
particular  military  component  to  autonomously  monitor  changes  within  each  military 
service’s  SOA  in  order  to  mitigate  risks  associated  with  interoperability.  This 
organization  should  continue  to  provide  guidance  throughout  the  lifecycle  of  all  military 
SOA  systems. 
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Figure  14.  Multiple  SOA  Initiatives  Being  Developed  for  Each  Military  Service 

from  (PEO-C4I,  2008,  p.  22) 

CANES  is  taking  positive  steps  toward  successful  joint  interoperability  by 
participating  in  the  Multi-Service  SOA  Consortium  collaboration  effort  to  develop 
common  standards  that  will  provide  the  necessary  measures  for  joint  interoperability. 
Increasing  the  success  of  joint  interoperability  is  the  goal  of  the  Enterprise  Services 
Technical  Governance  Forum.  Figure  15  is  a  diagram  of  the  forum’s  basic  structure. 
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Figure  15.  DoD/DNI  Enterprise  Services  Technical  Governance  Forum 

from  (PEO-C4I,  2008,  p.  27). 

The  DoD  CIO  and  the  Director  of  National  Intelligence  (DNI)  CIO  are  co¬ 
chairing  the  forum  and  providing  guidance  as  new  recommendations  for  enterprise 
services  implementation.  This  is  a  promising  endeavor  that  may  improve  joint 
interoperability.  This  forum  is  set  up  for  implementation,  but  a  similar  organization  must 
exist  to  continue  to  govern  each  new  service  as  systems  evolve.  A  permanent  governance 
board  will  ensure  joint  interoperability  continues  as  new  services  are  added  and  obsolete 
services  are  removed. 

2.  Cost  Savings 

The  CANES  system  is  currently  in  an  early  acquisition  phase.  Multiple  industry 
days  and  RFI’s  have  been  issued,  but  the  RFP  will  not  be  available  until  August  2008. 
The  Navy  is  still  seeking  input  from  industry  before  finalizing  CANES  initial 
requirements;  therefore,  funding  requirements  are  not  clear  at  this  time.  Although 
funding  for  CANES  is  still  undetermined,  $21.6  million  has  been  allocated  to  CANES  for 
FY2009  (Roughead,  2008,  p.  6).  This  system  is  considered  “mission  critical  for  the  fleet 
and  is  a  priority  for  Navy  leadership”  (SPAWAR,  2008,  p.  3).  CANES  is  expected  to 
reduce  total  ownership  costs  through  the  use  of  SOA  and  OA.  The  commercial  market 


63 


has  already  shown  the  cost  benefits  of  using  SOA  (Erickson,  2006,  p.  6).  As  DoD  SOA 
and  OA  initiatives  materialize,  cost  savings  should  be  realized  through  greater 
commonality  and  reduced  redundancy. 

In  2001,  AT&T  adopted  the  use  of  Web-services  that  would  move  towards  a  true 
SOA  by  2003.  The  initial  resistance  to  using  an  SOA  was  solved  by  AT&T’s  senior  vice 
president  stating  "Thou  shalt  use  Web  services,"  and  "If  you  don't  use  Web  services, 
you'll  get  fired”  (McKendrick,  2006).  This  example  of  change  management  was  required 
to  move  AT&T  towards  using  a  true  SOA.  The  benefits  have  shown  real  cost  savings 
within  5  years  of  starting  its  SOA  initiative.  “By  2005  AT&T  had  documented  over  $40 
million  in  savings  from  SOA”  (Erickson,  2006,  p.  6).  AT&T  also  projects  that  it  will  see 
an  additional  $100  million  in  cost  savings  by  2009.  AT&T  has  benefited  from  SOA’s 
ability  to  re-use  services,  reduce  maintenance  through  reduced  interfaces  and  versioning, 
and  increase  commonality  across  SOA  customer  interfaces.  Figure  16  illustrates  the  cost 
savings  AT&T  was  able  to  achieve  by  the  re-use  of  a  single  service  across  5  clients. 


Figure  16.  AT&T  Cost  Savings  from  (Erickson,  2006,  p.  6) 
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AT&T  is  a  large  enterprise  that  can  be  compared  to  the  Naval  enterprise.  The 
Navy  Leadership  has  already  mandated  using  OA  and  considers  SOA  a  priority. 

The  Consolidated  Afloat  Networks  and  Enterprise  Services  (CANES) 
system  achieves  an  open,  agile,  flexible  and  affordable  network 
architecture  that  will  move  us  forward.  CANES  embraces  cross-domain 
solutions  that  enable  enhanced  movement  of  data.  It  is  a  revolutionary 
change  in  our  infonnation  technology  infrastructure  and  it  is  absolutely 
vital  for  us  to  excel  in  21st  century  warfare.  (Roughead,  2008,  p.  6) 

Roughead’s  statement  is  similar  to  the  AT&T  vice  president’s  statement  in  that  it 
embraces  the  use  of  SOA  (through  CANES).  Just  as  AT&T  has  benefited  through  its 
SOA  implementation,  the  Navy  can  expect  to  achieve  similar  benefits  through  its  SOA 
implementation  with  CANES.  As  the  number  of  clients/customers  of  the  services 
provided  by  AT&T’s  SOA  increases,  their  cost  savings  increase.  As  the  Navy 
implements  CANES  across  different  platforms,  it  too  can  expect  an  increase  in  cost 
savings.  Greater  cost  savings  will  accrue  as  DoD  military  components  increase 
information  sharing  among  each  military  service  through  common  SOA  interfaces. 

E.  SUMMARY 

This  chapter  analyzed  the  Navy’s  SOA  implementation  within  CANES.  The 
chapter  started  with  a  broad  overview  of  CANES  and  what  it  is  trying  to  accomplish,  then 
it  discussed  how  the  Navy  plans  to  implement  SOA  within  CANES  and  how  it  adheres  to 
SOA  and  OA  principles  and  practices.  The  chapter  then  discussed  how  CANES  will 
utilize  SOA  and  OA  to  provide  future  IWS  capabilities.  This  chapter  and  this  case  study 
provided  answers  to  the  second  and  third  thesis  questions,  “Do  current  Navy  OA  policies 
and  SOA  practices  provide  the  necessary  interoperability  requirements  for  future  IWS?” 
and  “What  benefits  might  SOA  and  OA  provide  to  IWS?” 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

The  main  purpose  of  this  thesis  was  to  analyze  whether  the  Defense  Acquisition 
System  needs  to  be  altered  to  take  advantage  of  the  implementation  of  Services-oriented 
Architecture  (SOA)  and  Open  Architecture  (OA)  principles  into  the  acquisition  of 
Integrated  Warfare  Systems  (IWS).  The  research  behind  this  thesis  had  several 
objectives.  The  researchers  began  by  examining  SOA  and  OA  principles  and  processes 
to  satisfy  the  first  objective  of  detennining  the  relational  architecture  between  SOA  and 
OA  systems.  The  researchers  then  examined  the  Defense  Acquisition  System  and  the 
acquisition  lifecycle  to  satisfy  the  second  objective  of  determining  the  feasibility  of 
moving  toward  SOA  and  OA  systems.  This  examination  of  the  Defense  Acquisition 
System  then  lead  to  satisfying  the  third  objective  of  identifying  any  possible  constraints 
within  the  Defense  Acquisition  System  that  would  prevent  the  implementation  of  SOA 
and  OA  in  IWS.  The  researchers  examined  the  Consolidated  Afloat  Networks  and 
Enterprise  Services  (CANES)  program  to  satisfy  the  fourth  objective,  which  was  to 
determine  the  best  practices  of  a  Naval  acquisition  program  that  is  currently 
implementing  SOA  and  OA  into  its  acquisition  process.  Finally,  the  researchers 
examined  some  other  Navy  and  DoD  initiatives  to  satisfy  the  final  objective  of 
establishing  some  successful  realignments  of  the  Defense  Acquisition  System  to  allow 
new  technology  acquisition  in  military  organizations. 

The  research  objectives  of  this  thesis  were  established  and  fulfilled  to  enable  the 
researchers  to  answer  three  thesis  questions;  “Does  the  Defense  Acquisition  System  need 
to  be  altered  to  take  advantage  of  SOA  and  OA  implementation  into  the  acquisition 
lifecycle?”,  “Do  current  Navy  OA  policies  and  SOA  practices  provide  the  necessary 
interoperability  requirements  for  future  IWS?”  and  “What  benefits  might  SOA  and  OA 
provide  to  IWS?” 
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Chapter  III  provided  a  detailed  examination  of  the  Defense  Acquisition  System 
and  the  answer  to  the  first  thesis  question,  “Does  the  Defense  Acquisition  System  need  to 
be  altered  to  take  advantage  of  SOA  and  OA  implementation  into  the  acquisition 
lifecycle?”  From  the  analysis  of  the  current  Defense  Acquisition  System,  the  researchers 
conclude  that  the  implementation  of  SOA  and  OA  does  not  require  a  necessity  to  alter  the 
current  processes.  The  requirement  for  using  a  modular  open  systems  approach  (MOSA) 
within  the  Defense  Acquisition  System  enables  rather  than  inhibits  implementing  SOA 
and  OA.  Although  the  service  delivery  lifecycle  stages  of  an  SOA  do  not  completely  fit 
with  the  defense  acquisition  management  framework,  the  flexibility  of  the  framework 
allows  the  procedures  and  processes  to  be  tailored  to  meet  the  needs  of  implementing  an 
SOA.  The  DoDD  5000.1  and  DoDI  5000.2  provide  the  necessary  guidelines  for 
developing  and  acquiring  emerging  technologies  such  as  SOA  and  OA.  The  emphasis  of 
implementing  SOA  and  OA  into  future  IWS  needs  to  come  from  the  policies  and 
guidance  set  forth  by  the  Navy.  To  further  OA  use  within  Naval  systems,  the  Navy 
should  begin  to  combine  the  use  of  OA  with  other  emerging  technologies  such  as  SOA 
and  service-oriented  computing.  The  Navy  must  eliminate  the  traditional  “stove-piped” 
acquisition  process  (in  which  each  platfonn  acquired  its  own  combat  systems)  and  move 
toward  a  horizontal  acquisition  process  in  which  combat  systems  are  acquired  and 
integrated  across  multiple  platforms. 

Chapter  IV  provided  a  short  analysis  of  the  CANES  program  and  the  answers  to 
the  second  and  third  thesis  questions,  “Do  current  Navy  OA  policies  and  SOA  practices 
provide  the  necessary  interoperability  requirements  for  future  IWS?”  and  “What  benefits 
might  SOA  and  OA  provide  to  IWS?”  After  analysis  of  the  CANES  program,  the  authors 
concluded  that  the  Navy  is  proceeding  in  the  correct  direction  to  meet  future  warfighter 
needs  by  using  OA  and  SOA  in  CANES  to  support  future  IWS.  Although  CANES  is  still 
in  its  infancy  as  a  program,  having  not  yet  released  an  RFP,  it  is  following  current  SOA 
and  OA  policies  and  practices  in  order  to  provide  the  interoperability  requirements  the 
Navy  desires  for  future  IWS.  As  the  Navy  continues  to  develop  CANES,  following 
commonly  accepted  SOA  methods  and  best  practices  will  increase  the  program’s  success. 
Since  requirements  are  likely  to  evolve  as  CANES  development  and  implementation 
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progresses,  adherence  to  common  SOA  and  OA  principles  and  practices  will  provide  the 
necessary  interoperability  and  agility  for  future  IWS.  CANES  participation  in  the  Multi- 
Service  SOA  Consortium  is  a  positive  step  toward  increasing  joint  interoperability.  The 
potential  cost  savings  benefit  from  CANES  and  the  increase  in  information  sharing  is 
also  evident.  As  illustrated  in  Chapter  IV,  AT&T  has  demonstrated  the  benefits  of 
migrating  from  legacy  systems  to  SOA.  Cost  savings  and  improved  infonnation  sharing 
will  increase  the  Navy’s  and  the  other  military  services’  warfighting  capabilities  in  the 
future.  The  CANES  program  is  the  first  step  towards  moving  from  the  Navy’s  current 
IWS  systems  to  future  systems  that  capitalize  on  the  benefits  of  utilizing  OA  and  SOA. 
CANES  is  an  early  step  toward  shifting  the  Navy’s  acquisition  system  from  a  vertical 
“stove-piped”  process  to  a  more  horizontal  process  that  will  provide  the  necessary 
interoperability  requirements  for  future  IWS. 

B.  RECOMMENDATIONS 

Based  on  their  conclusions,  the  researchers  have  developed  several 
recommendations  that  will  facilitate  the  Navy’s  transition  from  a  vertical  “stove-piped” 
acquisition  process  to  a  horizontal  acquisition  process.  The  first  recommendation  is  to  re¬ 
structure  the  current  PEO  system.  Chapter  III  discussed  the  concepts  behind  the  creation 
of  PEO-IWS  and  the  limitations  it  faces  due  to  current  funding  structures.  In  order  to 
create  a  truly  horizontal  acquisition  process  and  integrating  combat  systems  across 
multiple  platforms,  the  Navy  should  consider  re-structuring  the  current  PEO 
system-providing  PEO-IWS  with  not  only  the  authority  and  responsibility  to  design, 
construct  and  maintain  integrated  combat  systems,  but  also  to  provide  them  with  the 
proper  funding  and  the  control  of  that  funding. 

The  second  recommendation  is  to  establish  SOA  policies  and  guidance  within  the 
Navy  and  the  DoD.  The  Navy’s  policies  and  guidance  concerning  OA  have  begun  to 
catch  up  with  the  commercial  market  and  should  facilitate  the  implementation  of  OA  into 
future  combat  systems  acquisition  processes.  The  DON  SOA  Transfonnation  Group 
should  capitalize  on  the  current  Naval  OA  policies  and  guidance  when  developing  its 
SOA  policies  and  guidance.  The  Navy  will  also  need  to  develop  a  contracting  guidebook 
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for  program  managers  and  contracting  officers’  guidance  for  implementing  SO  A  into 
their  contracts.  Similar  to  the  Navy’s  OA  contract  guidebook,  the  SOA  contract 
guidebook  should  contain  suggested  language  for  Sections  C,  H,  L,  and  M  as  well  as 
recommendations  that  provide  incentives  to  contractors  for  utilizing  SOA.  SOA 
principles  and  policies  combined  with  OA  principles  and  policies  supports  horizontal 
systems  engineering  and  provides  a  path  for  the  transition  from  a  vertical  to  a  horizontal 
acquisition  process. 

The  third  recommendation  is  for  the  DoD  to  establish  a  continuous  joint  SOA 
governance  board  led  by  DoD  personnel  not  affiliated  with  a  particular  military  service. 
Joint  interoperability  is  imperative  for  all  future  DoD  IT  systems.  SOA  standards  are 
currently  in  development  through  the  Multi-Service  SOA  Consortium  and  the  Enterprise 
Services  Technical  Governance  Forum.  These  organizations  are  intended  to  develop 
common  standards  to  increase  the  interoperability  throughout  all  military  services.  Using 
these  organizations  increases  the  likelihood  of  each  military  service’s  SOA  program  to  be 
interoperable  when  implemented,  but  it  does  not  provide  the  necessary  means  for 
maintaining  interoperability  as  systems  mature.  The  establishment  of  a  continuous  joint 
SOA  governance  board  will  provide  the  necessary  governance  to  maintain  joint 
interoperability  as  systems  change.  The  board  will  monitor  changes  to  any  military  SOA 
program,  ensuring  new  service  implementations  adhere  to  approved  standards. 
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VI.  FUTURE  WORK 


While  conducting  the  research  and  writing  for  this  thesis,  the  researchers 
identified  several  issues  that  could  be  developed  and  addressed  by  future  NPS  thesis 
students. 

1.  Evaluation  of  the  PEO  System 

One  of  the  recommendations  of  the  researchers  is  the  re-structuring  of  the  PEO 
system.  One  of  the  limitations  facing  PEO-IWS  is  the  current  funding  structure.  A  thesis 
could  be  developed  that  would  evaluate  the  current  PEO  system  in  order  to  identity 
constraints  within  the  PEO  structure  that  inhibits  the  transition  from  a  vertical  to  a 
horizontal  acquisition  process.  The  thesis  could  then  develop  recommendations  on  how 
to  re-structure  the  PEO  system  to  enable  a  horizontal  acquisition  process. 

2.  SOA  Policy  and  Guidance  Development 

Another  recommendation  provided  in  this  thesis  is  the  development  of  the  Navy’s 
SOA  policies  and  guidance.  A  thesis  student  could  work  directly  with  the  DON  SOA 
Transformation  Group  to  develop  a  thesis  that  would  provide  an  evaluation  on  both  the 
Navy’s  current  OA  policies  and  guidance  along  with  the  best  practices  of  the  commercial 
SOA  implementations.  This  thesis  could  provide  recommendations  for  the  development 
of  the  Navy’s  SOA  policies  and  guidance. 

3.  SOA  Contracting  Implications 

This  thesis  briefly  discussed  the  similarities  between  a  modular  open  systems 
approach  (MOSA)  acquisition  strategy  and  its  implication  on  the  contracting  process  and 
the  implications  of  SOA  within  the  contracting  process.  A  graduate  student  could 
research  and  develop  a  thesis  that  evaluates  the  implications  of  SOA  within  an 
acquisition  strategy  and  the  contracting  process.  Since  the  CANES  program  is  currently 
developing  and  revising  its  acquisition  strategy  and  contracting  process,  it  would  provide 

a  case  example  in  which  the  graduate  student  could  develop  his  or  her  thesis. 

71 


4. 


Assess  Effectiveness  of  SOA  Implementation 


This  thesis  discussed  how  the  DoD’s  requirements  established  for  utilization  of  a 
MOSA  approach  enables  SOA.  Although  the  Navy  has  not  established  policies  that 
require  the  use  of  SOA,  it  still  desires  to  use  SOA.  One  of  the  recommendations  of  this 
thesis  was  to  establish  SOA  policies  within  the  Navy  and  DoD.  It  would  be  interesting  to 
know,  without  a  current  policy  requiring  the  use  of  SOA,  how  Program  Managers  (PM) 
and  Milestone  Decision  Authorities  (MDA)  are  implementing  SOA  into  their  programs. 
A  graduate  student  could  research  and  develop  a  thesis  that  assesses  the  effectiveness  of 
an  SOA  implementation  by  comparing  it  to  the  current  MOSA  implementation  within  the 
DoD.  If  PMs  and  MDAs  are  not  concerned  about  SOA  implementation,  they  may  not 
care  about  the  status  of  utilizing  an  SOA.  The  results  of  this  research  may  support  the 
need  for  the  Navy  and  DoD  to  establish  policies  that  require  the  use  of  SOA  similar  to 
those  policies  established  for  the  requirement  to  use  MOSA. 
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